From rschiele at uni-mannheim.de Thu Jul 1 11:43:54 2004 From: rschiele at uni-mannheim.de (Robert Schiele) Date: Thu, 1 Jul 2004 13:43:54 +0200 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm (#122922) Message-ID: <20040701114354.GC1549@schiele.dyndns.org> Hello! May I introduce one of our students Matthias Juchem who is intended to implement what is described in http://bugzilla.mozilla.org/show_bug.cgi?id=122922 in his thesis. As we are interested in merging this upstream afterwards, we present here his first personal thoughts on the topic to allow all stakeholders to give their thoughts or alternative proposals. All feedback is appreciated. This is what he wrote for a first shot: --- As noticed in bug #122922, SQL statements regarding bug data are split into multiple files, i.e. post_bug.cgi, process_bug.cgi and attachment.cgi; the mailgate code duplicates again some of that code. To simplify code maintenance I would like to change Bug.pm in a way so that it presents one interface for changing bug data that will/can be used by every other module that wants to change bug data in the database. This adds an abstraction layer for all other code being independent of the actual database implementation and even offers an opportunity for easy implementation of other backend drivers (e.g. storing bugs in different databases or even different storage media). - Most of the code from post_bug.cgi that sets the fields of a new bug according to the form fields should be moved in a new routine, say Bugzilla::Bug::new_bug(), which shall be independent of the CGI data structure. This should also simplify the interaction with a new mail interface. This function should initialize the Bug object only with a bare minimum standard configuration for the new bug. Further settings will then be done by the following functions. - There should be a few routines for changing the content of a bug (to be used by process_bug.cgi and attachment.cgi): * Bugzilla::Bug::add_attachment() for adding a new attachment * Bugzilla::Bug::add_comment() for adding a new comment * Bugzilla::Bug::set_flag() for setting flags, obviously * Bugzilla::Bug::set_field() for changing values of the bug table (roughly) * and maybe a few more that will come up during the following discussion or during further design and implementation. - As doing an UPDATE for each single change would be kind of slow, Bugzilla::Bug should remember the changes and Bugzilla::Bug::commit() has to be called to issue an UPDATE. - Authorization, e.g. CheckCanChangeField from process_bug.cgi, would also be part of Bug.pm. --- Matthias and Robert -- Robert Schiele Tel.: +49-621-181-2517 Dipl.-Wirtsch.informatiker mailto:rschiele at uni-mannheim.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugreport at peshkin.net Thu Jul 1 17:55:16 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 01 Jul 2004 10:55:16 -0700 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm (#122922) In-Reply-To: <20040701114354.GC1549@schiele.dyndns.org> References: <20040701114354.GC1549@schiele.dyndns.org> Message-ID: <40E45004.9030300@peshkin.net> Robert Schiele wrote: >Hello! > >May I introduce one of our students Matthias Juchem > who is intended to implement what is described in >http://bugzilla.mozilla.org/show_bug.cgi?id=122922 in his thesis. > > I am glad to see code contributions coming in this way. Hopefully, he is prepared to have 16 advisors :-) How long do you expect this project to take? Have you landed pathces before? > > >- Authorization, e.g. CheckCanChangeField from process_bug.cgi, would also be > part of Bug.pm. > > > One caution... We expect that users may have customized CheckCanChangeField and expect to be able to continue to upgrade after making such a customization. Even moving the routing to another module will cause them some difficulty which is probably unavoidable. However, it should be extremely clear how we expect them to migrate from an old version to the new version and how they should structure their changes to make future merges as simple as possible. -Joel From kiko at async.com.br Thu Jul 1 18:09:12 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 1 Jul 2004 15:09:12 -0300 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm (#122922) In-Reply-To: <40E45004.9030300@peshkin.net> References: <20040701114354.GC1549@schiele.dyndns.org> <40E45004.9030300@peshkin.net> Message-ID: <20040701180912.GE1462@async.com.br> On Thu, Jul 01, 2004 at 10:55:16AM -0700, Joel Peshkin wrote: > We expect that users may have customized CheckCanChangeField and > expect to be able to continue to upgrade after making such a > customization. Why not offer a customization hook in CheckCanChangeField instead or relying on people to customize the function itself? BTW, this has everything to do with what I just proposed in my latest comment to http://bugzilla.mozilla.org/show_bug.cgi?id=248386 Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From gerv at mozilla.org Thu Jul 1 21:18:37 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 01 Jul 2004 22:18:37 +0100 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm (#122922) In-Reply-To: <20040701180912.GE1462@async.com.br> References: <20040701114354.GC1549@schiele.dyndns.org> <40E45004.9030300@peshkin.net> <20040701180912.GE1462@async.com.br> Message-ID: <40E47FAD.5030508@mozilla.org> Christian Robottom Reis wrote: > Why not offer a customization hook in CheckCanChangeField instead or > relying on people to customize the function itself? Because it's not really that simple. People may want to change the existing logic, remove from it, add to it, whatever. You can't just call an extra function at the end and expect them to code it to to fix things up. CheckCanChangeField() _is_ the customisation hook. Gerv From gerv at mozilla.org Thu Jul 1 21:51:48 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 01 Jul 2004 22:51:48 +0100 Subject: bz-devel entity? In-Reply-To: <20040630205308.GA59630@barnson.org> References: <20040630205308.GA59630@barnson.org> Message-ID: <40E48774.2090206@mozilla.org> Matthew P. Barnson wrote: > Anybody mind if I nuke the two locations we're using that so that it > will be perfectly valid XML? No objections. Gerv From matthew at barnson.org Thu Jul 1 21:58:15 2004 From: matthew at barnson.org (Matthew P. Barnson) Date: Thu, 1 Jul 2004 15:58:15 -0600 Subject: bz-devel entity? In-Reply-To: <40E48774.2090206@mozilla.org> References: <20040630205308.GA59630@barnson.org> <40E48774.2090206@mozilla.org> Message-ID: <20040701215814.GK59630@barnson.org> The downside is that we're going to lose the "Development Release" flag on all the Guide pages until someone figures out how to do that particular type of Docbook entity in valid XML... -- Matthew P. Barnson - - - - Thought for the moment: In Blythe, California, a city ordinance declares that a person must own at least two cows before he can wear cowboy boots in public. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From rschiele at uni-mannheim.de Fri Jul 2 07:51:57 2004 From: rschiele at uni-mannheim.de (Robert Schiele) Date: Fri, 2 Jul 2004 09:51:57 +0200 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm (#122922) In-Reply-To: <40E45004.9030300@peshkin.net> References: <20040701114354.GC1549@schiele.dyndns.org> <40E45004.9030300@peshkin.net> Message-ID: <20040702075157.GA13126@schiele.dyndns.org> On Thu, Jul 01, 2004 at 10:55:16AM -0700, Joel Peshkin wrote: > I am glad to see code contributions coming in this way. Hopefully, he > is prepared to have 16 advisors :-) Part of my job is to protect him from doing random things just because everybody wants something else. After all I will have to do the final negotiations with him what his implementation has to provide and what not, even when the risk of this is that it will not get merged upstream. Although I hope the latter will not happen. > How long do you expect this project to take? Have you landed pathces > before? The project currently is scheduled for about three months. I hope that this time frame is enough to provide at least a stable basis to continue work on. I have not provided patches for Bugzilla yet, but for some other projects. The reason for raising this project is that I have personal interest in the Bugzilla project. For now we will just wait some days for some more interesting remarks on the proposal to collect and think about them... Happy hacking^H^H^H^H^H^H^Hcommenting! ;-) Robert -- Robert Schiele Tel.: +49-621-181-2517 Dipl.-Wirtsch.informatiker mailto:rschiele at uni-mannheim.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kiko at async.com.br Fri Jul 2 14:43:11 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 2 Jul 2004 11:43:11 -0300 Subject: Small Bugzilla layout survey Message-ID: <20040702144311.GB1351@async.com.br> I've written a short layout survey of Bugzilla installations in my weblog: http://www.async.com.br/~kiko/diary.html?date=02.07.2004 If anyone is considering a different customization, or has an interesting layout to post, I'd be happy to hear about it. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From dswegen at software.plasmon.com Fri Jul 2 14:50:12 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Fri, 2 Jul 2004 15:50:12 +0100 Subject: Small Bugzilla layout survey In-Reply-To: <20040702144311.GB1351@async.com.br> References: <20040702144311.GB1351@async.com.br> Message-ID: <20040702145012.GN24106@software.plasmon> On Fri, Jul 02, 2004 at 11:43:11AM -0300, Christian Robottom Reis wrote: > > I've written a short layout survey of Bugzilla installations in my > weblog: > > http://www.async.com.br/~kiko/diary.html?date=02.07.2004 > > If anyone is considering a different customization, or has an > interesting layout to post, I'd be happy to hear about it. > KDE have modified theirs a fair amount. Of course I have no idea if it looks like any of the ones you posted, because I'm simply too lazy to check. But it does have at least one feature I really like, which is the way important data about a bug is placed in a box in edit_bugs.cgi. Cheers Dave From mkanat at kerio.com Fri Jul 2 23:26:37 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Fri, 02 Jul 2004 16:26:37 -0700 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <20040701114354.GC1549@schiele.dyndns.org> References: <20040701114354.GC1549@schiele.dyndns.org> Message-ID: <1088810797.3785.42.camel@localhost.localdomain> > - Most of the code from post_bug.cgi that sets the fields of a new bug > according to the form fields should be moved in a new routine, say > Bugzilla::Bug::new_bug(), which shall be independent of the CGI data > structure. Instead of this, I would highly recommend a *private* constructor that is not exposed as an API element, and a public "create" function, that initializes the bug in the DB. The constructor should only make the bug in RAM as an object; putting the thing into the DB or modifying the DB in any way should be a separate "static factory method." > - There should be a few routines for changing the content of a bug (to be used > by process_bug.cgi and attachment.cgi): > > * Bugzilla::Bug::add_attachment() for adding a new attachment > > * Bugzilla::Bug::add_comment() for adding a new comment > > * Bugzilla::Bug::set_flag() for setting flags, obviously > > * Bugzilla::Bug::set_field() for changing values of the bug table (roughly) That would be great. Those all sound perfect. The interesting discussion, of course, is what the parameters should be. If I have a bug with a lot of fields, I will probably also want a convenience function that takes an array of hashes that contain field names and their values, so I can just stick them all in at once (and quickly). I think that set_field will be the most difficult -- setting some fields has a side effect. For example, the syntax for adding a CC might warrant its own function, since I can simultaneously add and remove CCs. (True, I could just have a function that takes the new setting of all the addresses; I suppose that wouldn't be so bad. I feel like there are bad things lurking in that solution that I can't think of, though.) Oh, you could probably also use a get_ version for all of these. > - As doing an UPDATE for each single change would be kind of slow, > Bugzilla::Bug should remember the changes and Bugzilla::Bug::commit() has to > be called to issue an UPDATE. SELECT should probably work in the same sense, if we have the get_ functions. > - Authorization, e.g. CheckCanChangeField from process_bug.cgi, would also be > part of Bug.pm. I was thinking the same thing. -Max From justdave at bugzilla.org Sat Jul 3 00:05:48 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 02 Jul 2004 20:05:48 -0400 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <1088810797.3785.42.camel@localhost.localdomain> References: <20040701114354.GC1549@schiele.dyndns.org> <1088810797.3785.42.camel@localhost.localdomain> Message-ID: <40E5F85C.6030701@bugzilla.org> Max Kanat-Alexander wrote: >>- Authorization, e.g. CheckCanChangeField from process_bug.cgi, would also be >> part of Bug.pm. > > I was thinking the same thing. My take on this, for ease of customization, is that the CheckCanChangeField function should be placed in its own .pm or .pl file all by itself. If possible, with all of the "housekeeping" stuff moved elsewhere (back into Bug.pm?), so only things that are actually considered "rules" are in the file. (There are several default rules in there as we ship it) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bugzilla-bugpm at konfido.de Sat Jul 3 05:41:45 2004 From: bugzilla-bugpm at konfido.de (Matthias Juchem) Date: Sat, 3 Jul 2004 07:41:45 +0200 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <1088810797.3785.42.camel@localhost.localdomain> References: <20040701114354.GC1549@schiele.dyndns.org> <1088810797.3785.42.camel@localhost.localdomain> Message-ID: <200407030741.46040.bugzilla-bugpm@konfido.de> Hi. Disclaimer: There might be some little errors in this as I just got up and have not had very much sleep ;) Am Samstag, 3. Juli 2004 01:26 schrieb Max Kanat-Alexander: > > - Most of the code from post_bug.cgi that sets the fields of a new bug > > according to the form fields should be moved in a new routine, say > > Bugzilla::Bug::new_bug(), which shall be independent of the CGI data > > structure. > > Instead of this, I would highly recommend a *private* constructor that > is not exposed as an API element, and a public "create" function, that > initializes the bug in the DB. The constructor should only make the bug > in RAM as an object; putting the thing into the DB or modifying the DB > in any way should be a separate "static factory method." For the new bug case, I have had something like this in my mind: 1. new_bug() - creates an Bug object; does not update the database 2. set_field(), set_flags() and so on 3. set_defaults_for_missing_fields() (or some shorter name) that sets default values for things like assigned_to if they have not been specified in the form. 4. commit() - updates the database, i.e. allocates a new bug number and writes everything into the correct tables. And the old bug case for comparison: 1. new($bugid) 2. set_field() or whatever 3. commit() > > * Bugzilla::Bug::add_attachment() for adding a new attachment [..] > That would be great. Those all sound perfect. The interesting > discussion, of course, is what the parameters should be. Bugzilla::Bug::set_field($fieldname,$new_value) > If I have a bug > with a lot of fields, I will probably also want a convenience function > that takes an array of hashes that contain field names and their values, > so I can just stick them all in at once (and quickly). Convenience function should be easy to put on top of the basic set_whatever functions. > I think that set_field will be the most difficult -- setting some > fields has a side effect. For example, the syntax for adding a CC might > warrant its own function, since I can simultaneously add and remove CCs. I will think about this, but having a quick look over process_bug.cgi, something like add_ccs() and remove_ccs() seems to be fine. > Oh, you could probably also use a get_ version for all of these. Sure. > > - As doing an UPDATE for each single change would be kind of slow, > > Bugzilla::Bug should remember the changes and Bugzilla::Bug::commit() > > has to be called to issue an UPDATE. > > SELECT should probably work in the same sense, if we have the get_ > functions. Currently, Bugzilla::Bug caches those things, see Bugzilla::Bug::groups(). Regards, Matthias From luis.villa at gmail.com Sat Jul 3 14:24:41 2004 From: luis.villa at gmail.com (Luis Villa) Date: Sat, 3 Jul 2004 10:24:41 -0400 Subject: Small Bugzilla layout survey In-Reply-To: <20040702144311.GB1351@async.com.br> References: <20040702144311.GB1351@async.com.br> Message-ID: <2cb10c4404070307247f224337@mail.gmail.com> On Fri, 2 Jul 2004 11:43:11 -0300, Christian Robottom Reis wrote: > > I've written a short layout survey of Bugzilla installations in my > weblog: > > http://www.async.com.br/~kiko/diary.html?date=02.07.2004 > > If anyone is considering a different customization, or has an > interesting layout to post, I'd be happy to hear about it. It's worth noting that GNOME stole from KDE, and not vice-versa. The KDE guys have generally been very cool about helping us out with tips and tricks. They deliberately basically remove everything except 'add comment' from people who don't have editbugs, and only about 20-some people have editbugs. I wonder if we could squeeze the bugzilla/SF integration patches out of Helix? I know a lot of SFs would kill for that... Luis From kiko at async.com.br Mon Jul 5 18:48:47 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 5 Jul 2004 15:48:47 -0300 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <40E5F85C.6030701@bugzilla.org> References: <20040701114354.GC1549@schiele.dyndns.org> <1088810797.3785.42.camel@localhost.localdomain> <40E5F85C.6030701@bugzilla.org> Message-ID: <20040705184847.GE1154@async.com.br> On Fri, Jul 02, 2004 at 08:05:48PM -0400, David Miller wrote: > My take on this, for ease of customization, is that the > CheckCanChangeField function should be placed in its own .pm or .pl file > all by itself. If possible, with all of the "housekeeping" stuff moved > elsewhere (back into Bug.pm?), so only things that are actually > considered "rules" are in the file. (There are several default rules in > there as we ship it) This is the sanest approach I've heard proposed so far -- It would be great to isolate this often-customized code into one file. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From justdave at bugzilla.org Tue Jul 6 06:00:15 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 06 Jul 2004 02:00:15 -0400 Subject: Bugzilla 2.18 Branch rules Message-ID: <40EA3FEF.5070207@bugzilla.org> We will be branching for Bugzilla 2.18 within the next couple days (Finally!!!) A couple rules for the 2.18 branch: There will be a new flag added for approval2.18. If you want to check in on the 2.18 branch, request this. (This works just like the existing approval2.16 flag for the 2.16 branch). In general, we only want low-risk high-impact bugfixes on the branch. If you think something qualifies, request the blocking2.18 flag, and I'll make a decision on it. *ANYTHING* that gets checked in on the branch also gets checked in on the trunk, unless there's some damn good reason it shouldn't be (like the section of code it belongs to has already been replaced by some new feature introduction on the trunk or something like that). Templates *DO* *NOT* *GET* *TOUCHED* unless *absolutely* necessary. This may seem a little harsh, but this is a necessity to give the localizers time to get their templates for 2.18 ready prior to the release. If we can promise the localizers that the templates won't change between now and 2.18, they can proceed with localizing without fear of their templates breaking, and perhaps have some of the localizations ready to be posted at the same time we release. I may make an exception to that last one for the HTML validation stuff. Those changes should be pretty minor though, and easy enough for the localizers to pick up on later. Any comments or questions, feel free to speak up. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bugreport at peshkin.net Tue Jul 6 06:21:31 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 05 Jul 2004 23:21:31 -0700 Subject: Bugzilla 2.18 Branch rules In-Reply-To: <40EA3FEF.5070207@bugzilla.org> References: <40EA3FEF.5070207@bugzilla.org> Message-ID: <40EA44EB.5050105@peshkin.net> David Miller wrote: > > Templates *DO* *NOT* *GET* *TOUCHED* unless *absolutely* necessary. > This may seem a little harsh, but this is a necessity to give the > localizers time to get their templates for 2.18 ready prior to the > release. If we can promise the localizers that the templates won't > change between now and 2.18, they can proceed with localizing without > fear of their templates breaking, and perhaps have some of the > localizations ready to be posted at the same time we release. We need to figure out how the addition of new hooks interacts with this. From gerv at mozilla.org Tue Jul 6 16:21:51 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 06 Jul 2004 17:21:51 +0100 Subject: Bugzilla 2.18 Branch rules In-Reply-To: <40EA3FEF.5070207@bugzilla.org> References: <40EA3FEF.5070207@bugzilla.org> Message-ID: <40EAD19F.4010200@mozilla.org> David Miller wrote: > *ANYTHING* that gets checked in on the branch also gets checked in on > the trunk, unless there's some damn good reason it shouldn't be (like > the section of code it belongs to has already been replaced by some new > feature introduction on the trunk or something like that). Or it's a hacked fix for a deep problem that we are going to fix properly on the trunk? ;-) > Templates *DO* *NOT* *GET* *TOUCHED* unless *absolutely* necessary. Does this rule only apply before the 2.18 release, or for the entire lifetime of the branch? Gerv From james at enduring.com Tue Jul 6 08:55:05 2004 From: james at enduring.com (James Hale) Date: Tue, 6 Jul 2004 03:55:05 -0500 Subject: bugzilla on cygwin Message-ID: Am willing to admit maybe it was a bad idea to start, but have fair reasons to want this on my portable at the moment where have been running cygwin for years. Now have nearly hacked this to completion... was wondering if there was a writeup of the steps to get this working - or if writing down what it took once i'm done would be of interest. /james hale From justdave at bugzilla.org Tue Jul 6 17:18:26 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 06 Jul 2004 13:18:26 -0400 Subject: Bugzilla 2.18 Branch rules In-Reply-To: <40EAD19F.4010200@mozilla.org> References: <40EA3FEF.5070207@bugzilla.org> <40EAD19F.4010200@mozilla.org> Message-ID: <40EADEE2.6020901@bugzilla.org> Gervase Markham wrote: > David Miller wrote: > >> *ANYTHING* that gets checked in on the branch also gets checked in on >> the trunk, unless there's some damn good reason it shouldn't be (like >> the section of code it belongs to has already been replaced by some >> new feature introduction on the trunk or something like that). > > Or it's a hacked fix for a deep problem that we are going to fix > properly on the trunk? ;-) yeah. >> Templates *DO* *NOT* *GET* *TOUCHED* unless *absolutely* necessary. > > Does this rule only apply before the 2.18 release, or for the entire > lifetime of the branch? Lifetime of the branch. This has already been our policy with the 2.16 branch. The exceptions we made there were because of filtering problems, which were security fixes. We may make exceptions for the charting stuff for example (if that's what you're asking), since we really wanted that, and it's likely to be one of the last things the localizers would be translating anyway. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mkanat at kerio.com Tue Jul 6 18:23:59 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Tue, 06 Jul 2004 11:23:59 -0700 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <200407030741.46040.bugzilla-bugpm@konfido.de> References: <20040701114354.GC1549@schiele.dyndns.org> <1088810797.3785.42.camel@localhost.localdomain> <200407030741.46040.bugzilla-bugpm@konfido.de> Message-ID: <1089138239.32515.7.camel@localhost.localdomain> > 1. new_bug() - creates an Bug object; does not update the database > 2. set_field(), set_flags() and so on > 3. set_defaults_for_missing_fields() (or some shorter name) that sets default > values for things like assigned_to if they have not been specified in the > form. > 4. commit() - updates the database, i.e. allocates a new bug number and writes > everything into the correct tables. OK, sounds good. In case we ever go fully object-oriented with Bugzilla, I think when you create a bug it should have a flag called "comitted" that lets us know if it's actually in the DB or not. Of course, this could already be there, and I could just be unaware of it. :-) -Max From justdave at bugzilla.org Tue Jul 6 19:03:39 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 06 Jul 2004 15:03:39 -0400 Subject: Review statistics Message-ID: <40EAF78B.8030903@bugzilla.org> Just out of curiosity, I ran some stats last night on who's been doing reviews in Bugzilla. The results were pretty interesting. The following is a list of everyone who has either granted or denied a review in the Bugzilla product in the last 6 months, sorted by how many reviews they did. mysql> SELECT profiles.login_name, -> MAX(act.bug_when) AS last_review, -> COUNT(act.added) AS review_count -> FROM bugs_activity AS act -> INNER JOIN profiles ON act.who = profiles.userid -> INNER JOIN bugs ON act.bug_id = bugs.bug_id -> INNER JOIN products ON bugs.product_id = products.id -> WHERE DATE_SUB(NOW(),INTERVAL 6 MONTH) < act.bug_when -> AND (act.added = 'review+' OR act.added = 'review-') -> AND products.name = 'Bugzilla' -> GROUP BY profiles.login_name -> ORDER BY review_count DESC -> ; +--------------------------+---------------------+--------------+ | login_name | last_review | review_count | +--------------------------+---------------------+--------------+ | justdave at bugzilla.org | 2004-07-05 19:54:05 | 113 | | kiko at async.com.br | 2004-06-18 17:54:43 | 80 | | vladd at goobix.com | 2004-07-05 08:58:34 | 69 | | myk at mozilla.org | 2004-07-02 17:37:29 | 40 | | bugreport at peshkin.net | 2004-07-05 17:29:59 | 35 | | jouni at heikniemi.net | 2004-06-20 00:15:27 | 30 | | gerv at mozilla.org | 2004-06-19 04:46:45 | 28 | | bbaetz at acm.org | 2004-04-06 06:23:48 | 16 | | timeless at bemail.org | 2004-05-11 20:59:21 | 13 | | apeiron at comcast.net | 2004-03-27 14:24:24 | 2 | | erik at dasbistro.com | 2004-06-03 14:20:25 | 2 | | toms at myrealbox.com | 2004-04-17 05:40:03 | 1 | | zach at zachlipton.com | 2004-05-03 20:10:17 | 1 | | gleblanc at linuxweasel.com | 2004-03-07 23:36:24 | 1 | | preed at sigkill.com | 2004-05-13 08:34:05 | 1 | | john at johnkeiser.com | 2004-04-04 11:43:23 | 1 | +--------------------------+---------------------+--------------+ 16 rows in set (6.41 sec) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mkanat at kerio.com Tue Jul 6 19:01:04 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Tue, 06 Jul 2004 12:01:04 -0700 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <1089138239.32515.7.camel@localhost.localdomain> References: <20040701114354.GC1549@schiele.dyndns.org> <1088810797.3785.42.camel@localhost.localdomain> <200407030741.46040.bugzilla-bugpm@konfido.de> <1089138239.32515.7.camel@localhost.localdomain> Message-ID: <1089140464.2944.3.camel@localhost.localdomain> > > 3. set_defaults_for_missing_fields() (or some shorter name) that sets default > > values for things like assigned_to if they have not been specified in the > > form. > > 4. commit() - updates the database, i.e. allocates a new bug number and writes > > everything into the correct tables. Oh, one other comment -- this structure depends on a "the programmer must do this" sort of rule. That is, "You must always call Y and then Z." Designs that involve this tend to cause problems down the road, since not all programmers read API docs. At least, not until they get an error. :-) Either make sure it's enforced programmatically, or just roll step 3 into step 4. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From justdave at bugzilla.org Tue Jul 6 19:14:45 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 06 Jul 2004 15:14:45 -0400 Subject: bugzilla on cygwin In-Reply-To: References: Message-ID: <40EAFA25.2070109@bugzilla.org> James Hale wrote: > Am willing to admit maybe it was a bad idea to start, but have fair reasons > to want this on my portable at the moment where have been running cygwin for > years. > > Now have nearly hacked this to completion... was wondering if there was a > writeup of the steps to get this working - or if writing down what it took > once i'm done would be of interest. Yeah, writing up what you had to do might be useful. In theory, Bugzilla works out of the box on cygwin. So we'd definitely be interesting in finding out what doesn't quite work that way if that's not the case. Running outside of cygwin (with ActiveState Perl) is not exactly so fun. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bugzilla-bugpm at konfido.de Tue Jul 6 20:30:08 2004 From: bugzilla-bugpm at konfido.de (Matthias Juchem) Date: Tue, 6 Jul 2004 22:30:08 +0200 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <1089138239.32515.7.camel@localhost.localdomain> References: <20040701114354.GC1549@schiele.dyndns.org> <200407030741.46040.bugzilla-bugpm@konfido.de> <1089138239.32515.7.camel@localhost.localdomain> Message-ID: <200407062230.08333.bugzilla-bugpm@konfido.de> Am Dienstag, 6. Juli 2004 20:23 schrieb Maxwell Kanat-Alexander: > In case we ever go fully object-oriented with > Bugzilla, I think when you create a bug it should have a flag called > "comitted" that lets us know if it's actually in the DB or not. That's no problem. Bugzilla::Bug has to remember what fields have changed. So it's quite easy to see /whether/ one or more fields (or whatever) have changed. -- Kind regards, Matthias From bugzilla-bugpm at konfido.de Tue Jul 6 20:20:23 2004 From: bugzilla-bugpm at konfido.de (Matthias Juchem) Date: Tue, 6 Jul 2004 22:20:23 +0200 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <1089140464.2944.3.camel@localhost.localdomain> References: <20040701114354.GC1549@schiele.dyndns.org> <1089138239.32515.7.camel@localhost.localdomain> <1089140464.2944.3.camel@localhost.localdomain> Message-ID: <200407062220.23016.bugzilla-bugpm@konfido.de> Am Dienstag, 6. Juli 2004 21:01 schrieb Maxwell Kanat-Alexander: > > > 3. set_defaults_for_missing_fields() [..] > > > 4. commit() [..] > Oh, one other comment -- this structure depends on a "the programmer > must do this" sort of rule. That is, "You must always call Y and then > Z." Designs that involve this tend to cause problems down the road, > since not all programmers read API docs. At least, not until they get an > error. :-) That's true, but I guess one cannot expect an API to completely catch all programming errors. I don't know whether this potential error is worth the overhead described below. It's always a trade-off... > Either make sure it's enforced programmatically, or just roll step 3 > into step 4. IIRC, 3 will only be called for completely new errors as all required field should be filled with appropriate values. Therefore, calling 3 everytime when committing will result in quite a few unneeded calls. Not that calling 3 in 4 is a problem, but IMHO it's better to do this seperately. -- Kind regards, Matthias From mkanat at kerio.com Tue Jul 6 21:52:29 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Tue, 06 Jul 2004 14:52:29 -0700 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <200407062220.23016.bugzilla-bugpm@konfido.de> References: <20040701114354.GC1549@schiele.dyndns.org> <1089138239.32515.7.camel@localhost.localdomain> <1089140464.2944.3.camel@localhost.localdomain> <200407062220.23016.bugzilla-bugpm@konfido.de> Message-ID: <1089150749.3776.4.camel@localhost.localdomain> > That's true, but I guess one cannot expect an API to completely catch all > programming errors. I don't know whether this potential error is worth the > overhead described below. > > It's always a trade-off... Yes. However, an API should *never* expect a programmer to read it. An API should also never expect a programmer to run disrelated functions in a specified order without enforcing that order. In general, the rule of thumb is: It is never OK for one programmer to demand something of another programmer without enforcing it in code. > IIRC, 3 will only be called for completely new errors as all required field > should be filled with appropriate values. > Therefore, calling 3 everytime when committing will result in quite a few > unneeded calls. > > Not that calling 3 in 4 is a problem, but IMHO it's better to do this > seperately. OK. Then you can write a function called check_default_fields that quickly makes sure that all the default fields are filled in. I think it will add very little overhead, if commits are being batched anyway. Or, you could have a little flag called "defaults_filled," and check that quickly. That would be pretty simple, and would add even less overhead. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From bugzilla at glob.com.au Wed Jul 7 01:37:38 2004 From: bugzilla at glob.com.au (bugzilla at glob.com.au) Date: Wed, 7 Jul 2004 09:37:38 +0800 (WST) Subject: bugzilla on cygwin Message-ID: <20040707013738.7E70D89DB5@click.bur.st> > Yeah, writing up what you had to do might be useful. In theory, > Bugzilla works out of the box on cygwin. So we'd definitely be > interesting in finding out what doesn't quite work that way if that's > not the case. > > Running outside of cygwin (with ActiveState Perl) is not exactly so fun. i disagree :) (assuming bz 2.18 or thereabouts) there's only two extra steps involved in getting bugzilla running with activestate perl (and standard apache) vs cygwin perl and cygwin apache.. apache's "ScriptInterpreterSource" directive to work around the #! path issue, and sorting out the sendmail stuff, which can be kludged without touching the bz perl code. see http://www.glob.com.au/bugzilla/ -b begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From paulo.casanova at link.pt Wed Jul 7 11:31:35 2004 From: paulo.casanova at link.pt (Paulo Casanova) Date: Wed, 07 Jul 2004 12:31:35 +0100 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <1089150749.3776.4.camel@localhost.localdomain> Message-ID: Why not just fill in the default values when the bug is created in Bugzilla::Bug::new_bug() or whatever? This way new values would just be set over the default ones. Isn't that the Object-Oriented way? Paulo >> IIRC, 3 will only be called for completely new errors as all required field >> should be filled with appropriate values. >> Therefore, calling 3 everytime when committing will result in quite a few >> unneeded calls. >> >> Not that calling 3 in 4 is a problem, but IMHO it's better to do this >> seperately. > > OK. Then you can write a function called check_default_fields that > quickly makes sure that all the default fields are filled in. I think it > will add very little overhead, if commits are being batched anyway. > > Or, you could have a little flag called "defaults_filled," and check > that quickly. That would be pretty simple, and would add even less > overhead. > > -Max From gerv at mozilla.org Wed Jul 7 22:28:22 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 07 Jul 2004 23:28:22 +0100 Subject: Bugzilla Beta website In-Reply-To: <40E0F6DB.3010200@bugzilla.org> References: <40E0F6DB.3010200@bugzilla.org> Message-ID: <40EC7906.7060304@mozilla.org> David Miller wrote: > The preview version of the new www.bugzilla.org website is now available > at http://website-beta.bugzilla.org/ This rocks, BTW. Just thought I'd mention it. Kudos to whoever wrote the new content. We look very professional. Now we just need a new look for Bugzilla that's as nice ;-) > IF YOU HAVE CVS WRITE ACCESS TO THE WEBSITE, PLEASE NOTE: > Since the beta website now has real data on it, if you update anything > on the currently live website, make sure to also update the > corresponding page on the beta website, or your changes will likely be > lost when we make the beta site live. The beta site lives on the > MOZILLA_ORG_BRANCH, and updates to website-beta on the same schedule as > the live site. Can't we run some sort of automatic check when we switch over to catch stuff like this? I'm currently maintaining the installation list on the trunk, as it doesn't matter if the beta version is a little out of date, and it's a hassle to update both. Gerv From justdave at bugzilla.org Wed Jul 7 22:42:36 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 07 Jul 2004 18:42:36 -0400 Subject: Bugzilla Beta website In-Reply-To: <40EC7906.7060304@mozilla.org> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> Message-ID: <40EC7C5C.7000505@bugzilla.org> Gervase Markham wrote: > David Miller wrote: > >> The preview version of the new www.bugzilla.org website is now >> available at http://website-beta.bugzilla.org/ > > This rocks, BTW. Just thought I'd mention it. Kudos to whoever wrote the > new content. We look very professional. That'd be Mike Morgan. Original design gratuitously swiped from the one Dave Shea did for Mozilla.org and modified for Bugzilla by Mike. > Now we just need a new look for Bugzilla that's as nice ;-) Yeah, really. That's one of the things I keep hearing is Bugzilla still "looks" like a quick hack, even if it really isn't one under the hood anymore. > Can't we run some sort of automatic check when we switch over to catch > stuff like this? > > I'm currently maintaining the installation list on the trunk, as it > doesn't matter if the beta version is a little out of date, and it's a > hassle to update both. I'm not sure if it's worth it at this point... I think the new site is complete enough now (even if not all of the content has been rewritten yet) to go ahead and switch it over when we release 2.18rc1 in the next couple days. It's already a suitable replacement for the existing website, even if the enhanced content we wanted to also do isn't in place yet. For that one file (the installation list), I can remember to keep it when I pull everything else over. The cool part about the beta website: it's all in Template Toolkit. You can drop your installation list in there raw, and not bother running a script to convert it to HTML. The template will just load the file and convert it for you :) (I'm not sure if a template to do it that way has actually been done yet, but it should be a piece of cake to do). In fact, there is a MySQL server available on there... we could even put it in the database and use DBI to pull the data for the template if you want to do that. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mkanat at kerio.com Wed Jul 7 23:12:59 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Wed, 07 Jul 2004 16:12:59 -0700 Subject: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: References: Message-ID: <1089241979.3683.0.camel@localhost.localdomain> > Why not just fill in the default values when the bug is created in > Bugzilla::Bug::new_bug() or whatever? This way new values would just be set > over the default ones. Isn't that the Object-Oriented way? I think that sounds very sensible. Of course, I think that one of the things that we're running into is that new_bug can be called from an arbitrary state, and some of the defaults are product/component dependent. However, many defaults are global and could (and should) be set in new_bug(). :-) -Max From mike.morgan at oregonstate.edu Wed Jul 7 23:13:56 2004 From: mike.morgan at oregonstate.edu (Mike Morgan) Date: Wed, 07 Jul 2004 16:13:56 -0700 Subject: Bugzilla Beta website In-Reply-To: <40EC7C5C.7000505@bugzilla.org> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> Message-ID: <40EC83B4.2040300@oregonstate.edu> Gervase Markham wrote: > This rocks, BTW. Just thought I'd mention it. Kudos to whoever wrote > the new content. We look very professional. If any of you browse through and see other large blocks of content that need to be rewritten (particularly reduction of confusing wording, etc. -- kind of like how this parenthetical is) then please update bug #223043: http://bugzilla.mozilla.org/show_bug.cgi?id=223043 Additionally, don't forget that we're still looking for a more comprehensive list of Bugzilla features. We should fill out the features page (/features/) with more elaborate and sophisticated bragging. Somewhere on that page or elsewhere we might even consider user feedback. Or a "Bugzilla in the news" page. > Now we just need a new look for Bugzilla that's as nice ;-) I'd be interested in working on this after the website is 'complete'. Wasn't Christian doing some work on this? I really like GNOME's layout -- it's clean and professional but not much more complex: http://bugzilla.gnome.org/query.cgi > Can't we run some sort of automatic check when we switch over to catch > stuff like this? The best solution might just be to put the new site up as soon as possible. I'll fix the remaining stray broken links and then it's just a matter of time. :) Mike From luis.villa at gmail.com Thu Jul 8 03:41:35 2004 From: luis.villa at gmail.com (Luis Villa) Date: Wed, 7 Jul 2004 23:41:35 -0400 Subject: bugzilla look [was Re: Bugzilla Beta website] In-Reply-To: <40EC83B4.2040300@oregonstate.edu> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> Message-ID: <2cb10c440407072041e718714@mail.gmail.com> On Wed, 07 Jul 2004 16:13:56 -0700, Mike Morgan wrote: > Gervase Markham wrote: > > > This rocks, BTW. Just thought I'd mention it. Kudos to whoever wrote > > the new content. We look very professional. Seconded. or thirded. or something. > > Now we just need a new look for Bugzilla that's as nice ;-) > > I'd be interested in working on this after the website is 'complete'. > Wasn't Christian doing some work on this? > > I really like GNOME's layout -- it's clean and professional but not much > more complex: > http://bugzilla.gnome.org/query.cgi (1) credit where credit is due; much of this came from the guys who did www.gnome.org and bugs.kde.org. (2) You're welcome to steal/borrow/whatever as much as you want from there. Feel free to ask any questions about the CSS or whatever. Templates are available at http://cvs.gnome.org/viewcvs/bugzilla-new/template/ Luis From steve at boldapproach.com Wed Jul 7 22:15:50 2004 From: steve at boldapproach.com (Steve Watts) Date: Wed, 7 Jul 2004 16:15:50 -0600 Subject: Bugzilla Expert needed immediately Message-ID: <005a01c4646f$f6df8e10$6800a8c0@Steve> I have a client that just lost the person who was administering Bugzilla. I need a consultant for the following: 1. Train new Bugzilla Administer 2. Customization - Add an extra field for grouping 3. Fix an issue for priority bug reporting If you are interested in this project, please send me a summary of your expertise in Bugzilla and your hourly bill rate. The right consultant can start immediately and the work can be performed remotely. Thank you, Steve Watts CEO Bold Approach, Inc. Office: 208-323-2653 Cell: 208-850-3130 steve at boldapproach.com www.boldapproach.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiko at async.com.br Thu Jul 8 12:52:43 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 8 Jul 2004 09:52:43 -0300 Subject: Bugzilla Beta website In-Reply-To: <40EC83B4.2040300@oregonstate.edu> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> Message-ID: <20040708125242.GF714@async.com.br> On Wed, Jul 07, 2004 at 04:13:56PM -0700, Mike Morgan wrote: > >Now we just need a new look for Bugzilla that's as nice ;-) > > I'd be interested in working on this after the website is 'complete'. > Wasn't Christian doing some work on this? Either I'm supposed to or I'd love to, but changing the layout significantly is going to be something incredibly difficult to do without a go-ahead-and-we'll-support-you-through-the-good-and-the-bad from the team. I've been looking at some different designs the past week, and I have a good idea of what I should shoot for -- namely, simple changes that would improve usability and reduce confusion, as opposed to large redesigns that make Bugzilla unfamiliar in the short term. However, people need to agree to this approach before I commit to produce a bunch of template changes, particularly because they are *very* prone to bit-rotting unless we agree on them in a timely fashion. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From jth at mikrobitti.fi Thu Jul 8 12:57:32 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Thu, 8 Jul 2004 15:57:32 +0300 (EEST) Subject: Bugzilla Beta website In-Reply-To: <20040708125242.GF714@async.com.br> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> <20040708125242.GF714@async.com.br> Message-ID: On Thu, 8 Jul 2004, Christian Robottom Reis wrote: > I've been looking at some different designs the past week, and I have a > good idea of what I should shoot for -- namely, simple changes that > would improve usability and reduce confusion, as opposed to large > redesigns that make Bugzilla unfamiliar in the short term. However, > people need to agree to this approach before I commit to produce a bunch > of template changes, particularly because they are *very* prone to > bit-rotting unless we agree on them in a timely fashion. You should definitely present your ideas in static html form, avoiding the issues with bitrot. UI redesigns are incredibly hard to get consensus on; but anyway, a suggestion in the form of a static dummy would probably be a good way to see if there's any sense in trying to go further down that road. Jouni From kiko at async.com.br Thu Jul 8 13:21:56 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 8 Jul 2004 10:21:56 -0300 Subject: Bugzilla Beta website In-Reply-To: References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> <20040708125242.GF714@async.com.br> Message-ID: <20040708132156.GI714@async.com.br> On Thu, Jul 08, 2004 at 03:57:32PM +0300, Jouni Heikniemi wrote: > On Thu, 8 Jul 2004, Christian Robottom Reis wrote: > > > I've been looking at some different designs the past week, and I have a > > good idea of what I should shoot for -- namely, simple changes that > > would improve usability and reduce confusion, as opposed to large > > redesigns that make Bugzilla unfamiliar in the short term. However, > > people need to agree to this approach before I commit to produce a bunch > > of template changes, particularly because they are *very* prone to > > bit-rotting unless we agree on them in a timely fashion. > > You should definitely present your ideas in static html form, avoiding the > issues with bitrot. UI redesigns are incredibly hard to get consensus on; > but anyway, a suggestion in the form of a static dummy would probably be a > good way to see if there's any sense in trying to go further down that > road. My point is that if we are going to need to battle out consensus for details in the design we've already lost the war. UI designs aren't something that are well-disposed to arguing it out over bugs, and mpt, Firefox and the thousands of Mozilla UI bugs open have proven those points much better than I could. I agree that having an initial layout that shows the direction I'm suggesting we move towards is good, but what would be necessary after that is an initial `pre-approval' nod that said `we'll stick to your plan and trust you'll do it well'. I don't have an excess of time to invest on this, but I'd be willing to do it. My proposal would be to suggest some general guidelines on developers@, have a fixed period of time to discuss it, make a single mockup, and then just move on towards template changes. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From myk at mozilla.org Thu Jul 8 15:04:42 2004 From: myk at mozilla.org (Myk Melez) Date: Thu, 08 Jul 2004 08:04:42 -0700 Subject: Bugzilla Beta website In-Reply-To: <20040708132156.GI714@async.com.br> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> <20040708125242.GF714@async.com.br> <20040708132156.GI714@async.com.br> Message-ID: <40ED628A.6010106@mozilla.org> Christian Robottom Reis wrote: >My point is that if we are going to need to battle out consensus for >details in the design we've already lost the war. UI designs aren't >something that are well-disposed to arguing it out over bugs, and mpt, >Firefox and the thousands of Mozilla UI bugs open have proven those >points much better than I could. > > Agreed, and you don't need consensus. You only need my approval as UI component owner (or Dave's when you disagree with my decisions). >I agree that having an initial layout that shows the direction I'm >suggesting we move towards is good, but what would be necessary after >that is an initial `pre-approval' nod that said `we'll stick to your >plan and trust you'll do it well'. I don't have an excess of time to >invest on this, but I'd be willing to do it. > > I don't have a lot of time either, but I have enough to give you this nod for your overall endeavor and timely approval of the sequence of simple, small, iterative changes that gets us to the end-point, just as I've done (along with reviews) for the pair of CSS gurus who have been modifying our HTML one template at a time for CSS friendliness. >My proposal would be to suggest some general guidelines on developers@, >have a fixed period of time to discuss it, make a single mockup, and >then just move on towards template changes. > > Sounds good, except "have a fixed period of time to discuss it" should be "get input from others and come to agreement with Myk (or Dave)"; and note that some changes may require Perl code hacking in addition to template work. -myk From mswann at amazon.com Thu Jul 8 20:35:05 2004 From: mswann at amazon.com (Swann, Matthew) Date: Thu, 8 Jul 2004 13:35:05 -0700 Subject: Looking for Bugzilla RockStars Message-ID: <08399A9C7DB2294896E5ACBB120B60720391C1DC@ex-mail-sea-01.ant.amazon.com> This may be the wrong email list to distribute to but hopefully one of you can point me in the right direction. I'm looking into building a new bug-tracking/release management system from the ground up and am considering Bugzilla as a key component. Building this system will require additional permanent and contract staffing and consultation. I'm looking for engineers/consultants who have been there/done that with Bugzilla to help design, deliver and support a leading edge system for Amazon.com. Any help pointing me at people/firms would be greatly appreciated. Amazon is already 100% linux and most development is done in Perl/Mason (Presentation) with Java/C++/WebServices/Messaging on the backend/middle. Many of our packaging, deployment apps are based on opensource or are developed internally today. Regards, Matt Matt Swann Director, Platform Technology http://www.amazon.com -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Max Kanat-Alexander Sent: Wednesday, July 07, 2004 4:13 PM To: developers at bugzilla.org Subject: Re: Proposal for Abstraction Layer for Modifications in Bug.pm > Why not just fill in the default values when the bug is created in > Bugzilla::Bug::new_bug() or whatever? This way new values would just > be set over the default ones. Isn't that the Object-Oriented way? I think that sounds very sensible. Of course, I think that one of the things that we're running into is that new_bug can be called from an arbitrary state, and some of the defaults are product/component dependent. However, many defaults are global and could (and should) be set in new_bug(). :-) -Max - To view or change your list settings, click here: From gerv at mozilla.org Thu Jul 8 22:04:59 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 08 Jul 2004 23:04:59 +0100 Subject: Bugzilla Beta website In-Reply-To: <40ED628A.6010106@mozilla.org> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> <20040708125242.GF714@async.com.br> <20040708132156.GI714@async.com.br> <40ED628A.6010106@mozilla.org> Message-ID: <40EDC50B.2050906@mozilla.org> Myk Melez wrote: >> My proposal would be to suggest some general guidelines on developers@, >> have a fixed period of time to discuss it, make a single mockup, and >> then just move on towards template changes. >> > Sounds good, except "have a fixed period of time to discuss it" should > be "get input from others and come to agreement with Myk (or Dave)"; and > note that some changes may require Perl code hacking in addition to > template work. I would suggest that the best approach is to statically mock up a couple of key pages (query, buglist, show_bug) and pass them around for comment. That's not to say that you and Myk have to take any notice of the comments, but some people may have some good ideas. And doing static mockups allows people to take it and hack it to say "But what about if it looked like _this_?" and allows you to modify quicker based on feedback. Gerv From chicks at chicks.net Thu Jul 8 23:24:10 2004 From: chicks at chicks.net (chicks at chicks.net) Date: Thu, 8 Jul 2004 19:24:10 -0400 (EDT) Subject: new bugzilla look and feel In-Reply-To: <40EDC50B.2050906@mozilla.org> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> <20040708125242.GF714@async.com.br> <20040708132156.GI714@async.com.br> <40ED628A.6010106@mozilla.org> <40EDC50B.2050906@mozilla.org> Message-ID: On Thu, 8 Jul 2004, Gervase Markham wrote: >> Sounds good, except "have a fixed period of time to discuss it" should be >> "get input from others and come to agreement with Myk (or Dave)"; and note >> that some changes may require Perl code hacking in addition to template >> work. > > I would suggest that the best approach is to statically mock up a couple > of key pages (query, buglist, show_bug) and pass them around for > comment. That's not to say that you and Myk have to take any notice of > the comments, but some people may have some good ideas. And doing static > mockups allows people to take it and hack it to say "But what about if > it looked like _this_?" and allows you to modify quicker based on > feedback. I'd like to add a couple points: - The ultimate implementation of this look and feel would be best done with current CSS. This would tend to degrade reasonably to older systems while providing users of current browsers a prettier interface. - Red Hat has redesigned the user interface for bugzilla and has ended up with something that is certainly prettier than what we have now. Whether it would make a good or bad starting point I'm not sure. -- From mkanat at kerio.com Fri Jul 9 00:23:03 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Thu, 08 Jul 2004 17:23:03 -0700 Subject: new bugzilla look and feel In-Reply-To: References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> <20040708125242.GF714@async.com.br> <20040708132156.GI714@async.com.br> <40ED628A.6010106@mozilla.org> <40EDC50B.2050906@mozilla.org> Message-ID: <1089332582.9703.37.camel@localhost.localdomain> > - Red Hat has redesigned the user interface for bugzilla and has ended up > with something that is certainly prettier than what we have now. Whether > it would make a good or bad starting point I'm not sure. The nice thing about the Red Hat interface is: (1) It's pretty much all CSS. (2) The tabs at the top are cool. (3) It looks nice and professional. :-) The bad thing is: * It's based on 2.17.1. Of course, it will get an update to 2.18 as soon as 2.18 comes out. However, I don't think it will take advantage of new 2.18 features. (There's already a 2.18-beta version of the RH Bugzilla, up at some URL or other...) -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From jth at mikrobitti.fi Fri Jul 9 07:09:50 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Fri, 09 Jul 2004 10:09:50 +0300 Subject: Bugzilla Beta website In-Reply-To: <20040708132156.GI714@async.com.br> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> <20040708125242.GF714@async.com.br> Message-ID: <5.1.0.14.2.20040709100059.0b0cd4c0@mikrobitti.fi> At 10:21 8.7.2004 -0300, you wrote: >My point is that if we are going to need to battle out consensus for >details in the design we've already lost the war. UI designs aren't >something that are well-disposed to arguing it out over bugs, and mpt, >Firefox and the thousands of Mozilla UI bugs open have proven those >points much better than I could. I certainly didn't mean reaching consensus would a sensible target here. Myk's right; the approval of relevant parties is sufficient. Anyway, in a project where contributors come from very different backgrounds and have a vast spectrum of both web design and Bugzilla environemnt experience, it would be downright stupid not to take advantage of that in the planning phase - even when it comes to listening to suggestions about fairly minor details (such as the css stuff discussed on this list months ago). And again, not that we'd have to reach consensus nor that you'd have to obey any opinions. When the implementation decision is made, then it's time to shut up and see what appears. Before that, everything should be game and everyone should be listening. IMHO, of course. Jouni From kiko at async.com.br Fri Jul 9 14:53:10 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 9 Jul 2004 11:53:10 -0300 Subject: Bugzilla Beta website In-Reply-To: <5.1.0.14.2.20040709100059.0b0cd4c0@mikrobitti.fi> References: <40E0F6DB.3010200@bugzilla.org> <40EC7906.7060304@mozilla.org> <40EC7C5C.7000505@bugzilla.org> <40EC83B4.2040300@oregonstate.edu> <20040708125242.GF714@async.com.br> <5.1.0.14.2.20040709100059.0b0cd4c0@mikrobitti.fi> Message-ID: <20040709145310.GC684@async.com.br> On Fri, Jul 09, 2004 at 10:09:50AM +0300, Jouni Heikniemi wrote: > And again, not that we'd have to reach consensus nor that you'd have to > obey any opinions. When the implementation decision is made, then it's time > to shut up and see what appears. Before that, everything should be game and > everyone should be listening. IMHO, of course. Yeah, I just wanted to make it extra-clear that I want to avoid getting bogged down in design discussion on something that would require some serious effort. I aimed to overshoot, and it seems like I got what I asked for :-) Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From bugzilla-bugpm at konfido.de Fri Jul 9 15:51:04 2004 From: bugzilla-bugpm at konfido.de (Matthias Juchem) Date: Fri, 9 Jul 2004 17:51:04 +0200 Subject: Updated: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <20040701114354.GC1549@schiele.dyndns.org> References: <20040701114354.GC1549@schiele.dyndns.org> Message-ID: <200407091751.04551.bugzilla-bugpm@konfido.de> Hi. Because of the mails posted on the list, I have redone this text and incorporated some ideas presented in those mails. Please have a look at the result. I think I will start implementing some of this at the weekend As noticed in bug #122922, SQL statements regarding bug data are split into multiple files, i.e. post_bug.cgi, process_bug.cgi and attachment.cgi; the mailgate code duplicates again some of that code. To simplify code maintenance I would like to change Bug.pm in a way so that it presents one interface for changing bug data that will/can be used by every other module that wants to change or read bug data in the database. This adds an abstraction layer for all other code being independent of the actual database implementation and even offers an opportunity for easy implementation of other backend drivers (e.g. storing bugs in different databases or even different storage media). - Changing or adding a bug is split in multiple parts: * For new bugs only: Bugzilla::Bug::new(void) calls a new method createBug(), which initializes the Bug object only with a bare minimum standard configuration for the new bug making use of the default values for those fields. Bugzilla::Bug::createBug() does not issue an UPDATE to the database. * For existings bugs: Bugzilla::Bug::new($bugid) reads the bug data from the database by calling Bugzilla::Bug::initBug(). * Setting the data fields according to the web form fields is done via the set_*/add_* functions mentioned below. * As doing an UPDATE for each single change would be kind of slow, Bugzilla::Bug remebers the changes and commit(), being called at the end, issues an UPDATE. Before updating the data in the database, commit() checks for fields that have to be changed because they depend on other fields that have been changed. These checks will be put in a seperate method to allow easier customization. Therefore commit() also prevents inconsistent partial changes being written to the database. - There should be a few routines for changing the content of a bug (to be used by process_bug.cgi and attachment.cgi): * Bugzilla::Bug::add_attachment() for adding a new attachment * Bugzilla::Bug::add_comment() for adding a new comment * Bugzilla::Bug::set_flag($flagname,$value) for setting flags, obviously * Bugzilla::Bug::set_field($fieldname,$value) for changing values of the bug table (roughly) * Bugzilla::Bug::get_* for reading the values of an bug * and maybe a few more that will come up during the following discussion or during further design and implementation. - Authorization, e.g. CheckCanChangeField from process_bug.cgi, should be moved to a seperate Perl module so that it can be customized easily. This again allow easy customization. - The set_*/add_* functions above are low level functions that do nothing else than setting/adding the according variables. There will be some higher level routines for certain tasks, for example: * updating the CC list (addresses can be added and removed to/from the CC list at the same time) * changing multiple fields/flag at once -- Kind regards, Matthias From kiko at async.com.br Fri Jul 9 16:17:16 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 9 Jul 2004 13:17:16 -0300 Subject: Updated: Proposal for Abstraction Layer for Modifications in Bug.pm In-Reply-To: <200407091751.04551.bugzilla-bugpm@konfido.de> References: <20040701114354.GC1549@schiele.dyndns.org> <200407091751.04551.bugzilla-bugpm@konfido.de> Message-ID: <20040709161716.GA1229@async.com.br> On Fri, Jul 09, 2004 at 05:51:04PM +0200, Matthias Juchem wrote: > * Bugzilla::Bug::get_* for reading the values of an bug > > * and maybe a few more that will come up during the following discussion or > during further design and implementation. Hi Matthias, Just a note from my experience working on a time reporting feature these last week. Getting data in order to process it efficiently may preclude use of the Bug object in certain cases; this is admittedly a performance hack, but it's the sort of hack that allows reports to be generated in anything less than geological time. Just to serve as an illustration, one issue was that I needed to get back a set of times and bug IDs that were dependent on a single bug. I initially wanted to use bug objects, of course, and drill through its methods, but instantiating a bug object for each of the thousands of bugs I wanted was to be a major bottleneck, and I wrote the code to get back a collection of IDs and descriptions using a small loop of queries, and times for all of them using a single query. Since we're talking about database independence and so on -- not wanting to detract from your initiative, of course, since it is very relevant because many of Bugzilla operations today are done on very small collections of objects (at many times one or two) -- I thought it would be something to put forward. Reporting and complex searching may require separate interfaces if we want to be able to centralize the code while keeping things sane in databases with tens of thousands of bugs. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From harri.vartiainen at prosys.fi Fri Jul 9 09:01:50 2004 From: harri.vartiainen at prosys.fi (Harri Vartiainen) Date: Fri, 09 Jul 2004 12:01:50 +0300 Subject: Looking for Bugzilla RockStars In-Reply-To: <08399A9C7DB2294896E5ACBB120B60720391C1DC@ex-mail-sea-01.ant.amazon.com> References: <08399A9C7DB2294896E5ACBB120B60720391C1DC@ex-mail-sea-01.ant.amazon.com> Message-ID: <40EE5EFE.2020008@prosys.fi> Swann, Matthew wrote: >I'm looking for engineers/consultants who have been there/done that with Bugzilla to help design, deliver and support a leading edge system for Amazon.com. Any help pointing me at people/firms would be greatly appreciated. > > There's this page on Bugzilla homepage: http://www.bugzilla.org/consulting.html From gerv at mozilla.org Fri Jul 9 18:43:19 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 09 Jul 2004 19:43:19 +0100 Subject: Looking for Bugzilla RockStars In-Reply-To: <08399A9C7DB2294896E5ACBB120B60720391C1DC@ex-mail-sea-01.ant.amazon.com> References: <08399A9C7DB2294896E5ACBB120B60720391C1DC@ex-mail-sea-01.ant.amazon.com> Message-ID: <40EEE747.1090303@mozilla.org> Swann, Matthew wrote: > I'm looking for engineers/consultants who have been there/done that > with Bugzilla to help design, deliver and support a leading edge > system for Amazon.com. Any help pointing me at people/firms would be > greatly appreciated. http://www.bugzilla.org/consulting.html has a list of individuals and firms who have indicated they are available for this sort of work. That list does not attempt to discriminate between firms who have registered to be included. FWIW, the firms on the list who I personally know have employees actively involved in current Bugzilla code development are: Async Open Source Matthew Tuck Sigkill Consulting Gerv From mkgnu at gmx.net Fri Jul 9 19:10:04 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Fri, 09 Jul 2004 12:10:04 -0700 Subject: Looking for Bugzilla RockStars In-Reply-To: <08399A9C7DB2294896E5ACBB120B60720391C1DC@ex-mail-sea-01.ant.amazon.com> References: <08399A9C7DB2294896E5ACBB120B60720391C1DC@ex-mail-sea-01.ant.amazon.com> Message-ID: <1089400204.1579.9.camel@syd.mkgnu.net> Mathew, In my previous employer we ended up building such an in-house bug-tracking/release management system. We essentially integrated our version control tool (CVS at the time) with Bugzilla, and wrote extra scripts that would report bugs that went into a release (I did not participate in this -- someone else did this work). Since I left that employer I started writing from scratch this integration (with a different design and some extra goodies) with the ultimate goal of bulding such a release management system. I desperately needed this integration. You may be interested in the work I have available so far: http://freshmeat.net/projects/scmbug/ This was recently discussed in the Bugzilla mailing list, as I am currently pushing for a universal tool integrating source code version control with bug tracking. Cheers! Kristis On Thu, 2004-07-08 at 13:35, Swann, Matthew wrote: > This may be the wrong email list to distribute to but hopefully one of you can point me in the right direction. > > I'm looking into building a new bug-tracking/release management system from the ground up and am considering Bugzilla as a key component. Building this system will require additional permanent and contract staffing and consultation. > > I'm looking for engineers/consultants who have been there/done that with Bugzilla to help design, deliver and support a leading edge system for Amazon.com. Any help pointing me at people/firms would be greatly appreciated. > > Amazon is already 100% linux and most development is done in Perl/Mason (Presentation) with Java/C++/WebServices/Messaging on the backend/middle. Many of our packaging, deployment apps are based on opensource or are developed internally today. > > Regards, > > Matt > > Matt Swann > Director, Platform Technology > http://www.amazon.com > > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Max Kanat-Alexander > Sent: Wednesday, July 07, 2004 4:13 PM > To: developers at bugzilla.org > Subject: Re: Proposal for Abstraction Layer for Modifications in Bug.pm > > > Why not just fill in the default values when the bug is created in > > Bugzilla::Bug::new_bug() or whatever? This way new values would just > > be set over the default ones. Isn't that the Object-Oriented way? > > I think that sounds very sensible. > > Of course, I think that one of the things that we're running into is that new_bug can be called from an arbitrary state, and some of the defaults are product/component dependent. However, many defaults are global and could (and should) be set in new_bug(). :-) > > -Max > > > - > To view or change your list settings, click here: > > > - > To view or change your list settings, click here: > > From mkgnu at gmx.net Fri Jul 9 21:12:17 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Fri, 09 Jul 2004 14:12:17 -0700 Subject: Looking for Bugzilla RockStars In-Reply-To: <1089400204.1579.9.camel@syd.mkgnu.net> References: <08399A9C7DB2294896E5ACBB120B60720391C1DC@ex-mail-sea-01.ant.amazon.com> <1089400204.1579.9.camel@syd.mkgnu.net> Message-ID: <1089407537.1576.16.camel@syd.mkgnu.net> Whoops. Sorry for this one; it was intented for Matt Swann. The default "Reply-To" is starting to annoy me ;) From mkanat at kerio.com Sat Jul 10 00:34:20 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Fri, 09 Jul 2004 17:34:20 -0700 Subject: Updated: Proposal for Abstraction Layer for Modifications in In-Reply-To: <20040709161716.GA1229@async.com.br> References: <20040701114354.GC1549@schiele.dyndns.org> <200407091751.04551.bugzilla-bugpm@konfido.de> <20040709161716.GA1229@async.com.br> Message-ID: <1089419660.8393.7.camel@localhost.localdomain> > Just a note from my experience working on a time reporting feature > these last week. Getting data in order to process it efficiently may > preclude use of the Bug object in certain cases; this is admittedly a > performance hack, but it's the sort of hack that allows reports to be > generated in anything less than geological time. Hey Kiko. Yeah, I've run into this in other scripting languages than perl, too. Objects can be a big pain. I think what might help is Bug::read_fields($ids,$fieldnames) -- A simple abstraction that would be a static library function, and wouldn't instantiate any objects. It would just return the fields as an associative array from the bug id (or ids) that you requested. Also, it would probably help centralize a lot of SQL. :-) Granted, you don't get to do GROUP BY, ORDER BY, and aggregate functions, but it would still help in some situations, I'll bet. If I was designing a system from the ground-up, I'd probably make custom API functions for the various GROUP BY and ORDER BY things that needed to be done commonly, unless I couldn't come up with a way to keep it all manageable. (I'd really have to draw out a UML diagram to know for sure.) I think that several small SQL queries inside of one transaction (the result of such abstractions) wouldn't hurt performance. We basically do that now, in various places (except it's usually several large queries). -Max From mkanat at kerio.com Sat Jul 10 00:36:12 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Fri, 09 Jul 2004 17:36:12 -0700 Subject: DB Bottlenecks Message-ID: <1089419772.8393.10.camel@localhost.localdomain> As I was writing the last email that I wrote, I realized that I don't really know where the bottlenecks would be in Bugzilla, with regard to DB performance. Right now, it all pretty much seems to be perl performance that slows us down -- has anybody turned on slow_query logging in MySQL and picked out some common problems on large Bugzillas? Or done profiling of pages where it showed that significant time was being spent in the DB under certain situations? -Max From justdave at bugzilla.org Sat Jul 10 01:03:16 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 09 Jul 2004 21:03:16 -0400 Subject: DB Bottlenecks In-Reply-To: <1089419772.8393.10.camel@localhost.localdomain> References: <1089419772.8393.10.camel@localhost.localdomain> Message-ID: <40EF4054.60109@bugzilla.org> Maxwell Kanat-Alexander wrote: > As I was writing the last email that I wrote, I realized that I don't > really know where the bottlenecks would be in Bugzilla, with regard to > DB performance. > > Right now, it all pretty much seems to be perl performance that slows > us down -- has anybody turned on slow_query logging in MySQL and picked > out some common problems on large Bugzillas? Or done profiling of pages > where it showed that significant time was being spent in the DB under > certain situations? Yeah, it was done once a while back... we have several bugs filed already on the subject (some have been fixed already - I know one had to do with the way the CC table was being joined when searching for bugs by email address from the query page) It's been a couple years and the code's changed a lot though. Probably wouldn't hurt to do it again. I know next to zero of the load on bugzilla.mozilla.org is from the mysql server. The majority of the CPU time wasted by Bugzilla is on initialization of the Template Toolkit. That'll get solved when we get mod_perl working. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Sat Jul 10 01:56:27 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 09 Jul 2004 21:56:27 -0400 Subject: DB Bottlenecks In-Reply-To: <40EF4054.60109@bugzilla.org> References: <1089419772.8393.10.camel@localhost.localdomain> <40EF4054.60109@bugzilla.org> Message-ID: <40EF4CCB.2020308@bugzilla.org> David Miller wrote: > Maxwell Kanat-Alexander wrote: > >> As I was writing the last email that I wrote, I realized that I don't >> really know where the bottlenecks would be in Bugzilla, with regard to >> DB performance. On IRC, kiko said "showdependencytree" and "showdependencygraph". And yes, the queries we're using now to pull that information is not exactly efficient. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bbaetz at acm.org Sat Jul 10 02:04:40 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Sat, 10 Jul 2004 12:04:40 +1000 Subject: DB Bottlenecks In-Reply-To: <40EF4054.60109@bugzilla.org> References: <1089419772.8393.10.camel@localhost.localdomain> <40EF4054.60109@bugzilla.org> Message-ID: <20040710020440.GA3469@mango.home> On Fri, Jul 09, 2004 at 09:03:16PM -0400, David Miller wrote: > I know next to zero of the load on bugzilla.mozilla.org is from the > mysql server. The majority of the CPU time wasted by Bugzilla is on > initialization of the Template Toolkit. That'll get solved when we get > mod_perl working. On average, but there are still a bunch of bugist.cgi queries which can take ages. Plus the fact that youhave to run two mysql instances in order to get around the tbale level locking issue.... Bradley From gerv at mozilla.org Mon Jul 12 15:44:38 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 12 Jul 2004 16:44:38 +0100 Subject: Updated: Proposal for Abstraction Layer for Modifications in In-Reply-To: <200407091751.04551.bugzilla-bugpm@konfido.de> References: <20040701114354.GC1549@schiele.dyndns.org> <200407091751.04551.bugzilla-bugpm@konfido.de> Message-ID: <40F2B1E6.4000909@mozilla.org> Matthias Juchem wrote: > Because of the mails posted on the list, I have redone this text and > incorporated some ideas presented in those mails. Please have a look at the > result. I just want to say this is a good idea; it's needed doing for a while. Good luck :-) > To simplify code maintenance I would like to change Bug.pm in a way so that it > presents one interface for changing bug data that will/can be used by every > other module that wants to change or read bug data in the database. A noble goal; as kiko says, it might not quite work out that way in practice. But people always have the option of rolling their own if they need to. > * Setting the data fields according to the web form fields is done via the > set_*/add_* functions mentioned below. I would instead implement set(field_name, "value") get(field_name) plus a number of add_*("value") for things like comments and attachments. That way, you don't have to change the API of Bug.pm every time we change the fields in the bugs table in the database (which happens reasonably often), and it'll eliminate a lot of duplicated code. You can return a sensible error if the field name is not known. > Before updating the data in the database, commit() checks for fields that > have to be changed because they depend on other fields that have been > changed. These checks will be put in a seperate method to allow easier > customization. Same module as CheckCanChangeField(), perhaps. > Therefore commit() also prevents inconsistent partial changes being > written to the database. This sounds fine in theory; but there should be a way of overriding the checks in the api e.g. commit(FORCE)) so that things which have no way of sending feedback to the user are never messed up. > * Bugzilla::Bug::add_attachment() for adding a new attachment > > * Bugzilla::Bug::add_comment() for adding a new comment > Arguably, set() should not call commit(), but add_*() functions should. > - Authorization, e.g. CheckCanChangeField from process_bug.cgi, should be > moved to a seperate Perl module so that it can be customized easily. > This again allow easy customization. Sounds good. Ideally, it would be like auth now - you can specify the module name in params, so people can write their own modules and they won't have merge problems. Gerv From mkanat at us.kerio.com Tue Jul 13 01:40:14 2004 From: mkanat at us.kerio.com (Maxwell Kanat-Alexander) Date: Mon, 12 Jul 2004 18:40:14 -0700 Subject: DB Bottlenecks In-Reply-To: <20040710020440.GA3469@mango.home> Message-ID: <20040712184014.63f17387@mail.kerio.com> > On average, but there are still a bunch of buglist.cgi queries which can > take ages. Is that just because we actually have to scan in a lot of data for those queries, or is there actually an optimization that could be done there? -Max From bbaetz at acm.org Tue Jul 13 13:04:59 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Tue, 13 Jul 2004 23:04:59 +1000 Subject: DB Bottlenecks In-Reply-To: <20040712184014.63f17387@mail.kerio.com> References: <20040710020440.GA3469@mango.home> <20040712184014.63f17387@mail.kerio.com> Message-ID: <20040713130459.GA3023@mango.home> On Mon, Jul 12, 2004 at 06:40:14PM -0700, Maxwell Kanat-Alexander wrote: > > On average, but there are still a bunch of buglist.cgi queries which can > > take ages. > > Is that just because we actually have to scan in a lot of data for those queries, or is there actually an optimization that could be done there? It depends. In some cases its because mysql won't use more than one index per table. In others is because we can't optimise by using subselects, since mysql doesn't support thoses. There is, however, a lot of data to search through if you try silly queries ('all bugs with comments containing the letter e'), and no database can really help there. Bradley From bugreport at peshkin.net Tue Jul 13 13:10:05 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 13 Jul 2004 06:10:05 -0700 Subject: expecting mysql4 for large bugzilla sites?? Message-ID: <40F3DF2D.8070600@peshkin.net> Some upcoming changes to Search.pm to fix a number of search bugs would cause a performance slowdown for elaborate queries using Mysql 3, but would stay fast if the site is using mysql 4.0.14 or newer. Does it seem reasonable to expect larger sites that care about performance to use mysql4 ?? From asmodai at wxs.nl Tue Jul 13 13:16:20 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Tue, 13 Jul 2004 15:16:20 +0200 Subject: expecting mysql4 for large bugzilla sites?? In-Reply-To: <40F3DF2D.8070600@peshkin.net> References: <40F3DF2D.8070600@peshkin.net> Message-ID: <20040713131620.GZ1768@nexus.ninth-circle.org> -On [20040713 15:12], Joel Peshkin (bugreport at peshkin.net) wrote: >Does it seem reasonable to expect larger sites that care about >performance to use mysql4 ?? Wasn't 4.x going to be the preferred MySQL version for 2.20 and beyond anyway? -- Jeroen Ruigrok van der Werven / asmodai / kita no mono Free Tibet! http://www.savetibet.org/ | http://www.tibet.nu/ http://www.tendra.org/ | http://diary.in-nomine.org/ And with the last rays of the setting sun the loveless pulse fades away, no morebeating as one, no longer burns the flame... From mkanat at us.kerio.com Tue Jul 13 16:44:05 2004 From: mkanat at us.kerio.com (Maxwell Kanat-Alexander) Date: Tue, 13 Jul 2004 09:44:05 -0700 Subject: expecting mysql4 for large bugzilla sites?? In-Reply-To: <40F3DF2D.8070600@peshkin.net> Message-ID: <20040713094405.d54a3596@mail.kerio.com> > Does it seem reasonable to expect larger sites that care about > performance to use mysql4 ?? I think that this is completely reasonable, particularly if there's a note in the docs about it. In fact, I would even expect large sites to use MySQL 4.1, like Google and Yahoo do (according to MySQL). :-) I talked to some MySQL engineers at Apple's WWDC, and they say that as far as they're concerned, MySQL 4.1 is rock solid, and it just says "alpha" because the founders are really conservative. Also, they estimate September for MySQL 4.1 coming out of "alpha." -Max From justdave at bugzilla.org Wed Jul 14 02:59:16 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 13 Jul 2004 22:59:16 -0400 Subject: Bugzilla 2.18 localization Message-ID: <40F4A184.8010907@bugzilla.org> For those of you who are willing to prepare localized templates for Bugzilla 2.18, we have now frozen the template structure for 2.18, in order to let you guys have an easy time of updating the templates without having to wait for 2.18 to actually release. If you start with the templates that are available in the Bugzilla 2.18rc1 tarball, you can track any additional template changes since rc1 at this url: (link redirects into bonsai.mozilla.org) http://tinyurl.com/6j5nb As mentioned, the templates on the 2.18 branch are frozen. We will make changes to them if required for w3c validation purposes or for fixing of regressions or security bugs, but those changes should be minimal, and can be tracked at the above URL. There is one item pending regarding the charting system that may create a bit of upheaval in the templates related to charting, so leave those for last. :) (these would be search/search-create-series.html.tmpl and anything mentioning 'series' in the reports directory) If you get a localization up to date and ready to go, be sure to let me know so I can update the version list for your localization on the Bugzilla download page. Thanks again for everyone's efforts! -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From jth at mikrobitti.fi Wed Jul 21 05:36:21 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Wed, 21 Jul 2004 08:36:21 +0300 Subject: Proposal: Start requiring "code release notes" on a bug-level basis Message-ID: <40FE00D5.5070806@mikrobitti.fi> Hey ya, in the flurry of patches we've been receiving in the last few days, I've started to think about the problematic nature of heavy code reorganizations happening over a short span of time. Since the whole development team (not even the whole reviewer team) never takes part in developing a single patch, every now and then we check in a huge lump of code most people have never seen or even heard about. Yet, that code may change pretty familiar interfaces and ways to do everyday coding. For most of the time, hanging on the IRC and/or reading the bug will provide sufficient information, but nobody has the time to do that for all the bugs. This is why I think we should have "release notes" for significant changes to the codebase. These notes would be posted to developers@ at the time of checkin, and they should describe the new feature and the implications in the code. Notes shouldn't be required for things that are particularly internal to a method, module or another independent unit. In the end, I think only about 10-20% of the patches really need this... Here's a fictional example of what such a posting could look like (remember, this is just an example, the change described below hasn't occurred): -- Bug 123456 was just checked in. The modern SQL Statement execution using ->prepare and ->execute doesn't care about taints anymore, so you no longer have to trick_taint your variables prior to passing them to $sth->execute(). This is the correct way to do it: DB parameters are automatically quoted anyway. To summarize, you can now run SQL queries using the following syntax: my $dbh = Bugzilla->dbh; my $sth = $dbh->prepare("SELECT x, y FROM foo WHERE z = ?"); $sth->execute($cgi->param("z")); # taintedness no longer an issue here Remember that SendSQL et al. are deprecated. They will (naturally) still need the appropriate validation and detainting. -- Processwise, I think approval should be withheld until there is an acceptable proposal for notes available in the bug. It's then finally up to the approver to decide whether information about a certain change should be posted to developers at . It should be the responsibility of the person doing the checkin to make sure the notes actually get posted. Thoughts on this? Jouni From bugreport at peshkin.net Wed Jul 21 05:53:51 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 20 Jul 2004 22:53:51 -0700 Subject: Proposal: Start requiring "code release notes" on a bug-level In-Reply-To: <40FE00D5.5070806@mikrobitti.fi> References: <40FE00D5.5070806@mikrobitti.fi> Message-ID: <40FE04EF.4030805@peshkin.net> Jouni Heikniemi wrote: > > > Processwise, I think approval should be withheld until there is an > acceptable proposal for notes available in the bug. It's then finally > up to the approver to decide whether information about a certain > change should be posted to developers at . It should be the > responsibility of the person doing the checkin to make sure the notes > actually get posted. > I think this is a good idea, but we need a way to automatically pull those notes and compile them. From asmodai at wxs.nl Wed Jul 21 06:08:06 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Wed, 21 Jul 2004 08:08:06 +0200 Subject: Proposal: Start requiring "code release notes" on a bug-level In-Reply-To: <40FE04EF.4030805@peshkin.net> References: <40FE00D5.5070806@mikrobitti.fi> <40FE04EF.4030805@peshkin.net> Message-ID: <20040721060806.GH1768@nexus.ninth-circle.org> -On [20040721 08:02], Joel Peshkin (bugreport at peshkin.net) wrote: >I think this is a good idea, but we need a way to automatically pull >those notes and compile them. Prefix each post with a subject of [RELNOTES:] ? -- Jeroen Ruigrok van der Werven / asmodai / kita no mono Free Tibet! http://www.savetibet.org/ | http://www.tibet.nu/ http://www.tendra.org/ | http://diary.in-nomine.org/ Whatever you believe in, you will find close to your eyes to see... From bugreport at peshkin.net Wed Jul 21 11:40:28 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 21 Jul 2004 04:40:28 -0700 Subject: Proposal: Start requiring "code release notes" on a bug-level In-Reply-To: <20040721060806.GH1768@nexus.ninth-circle.org> References: <40FE00D5.5070806@mikrobitti.fi> <40FE04EF.4030805@peshkin.net> <20040721060806.GH1768@nexus.ninth-circle.org> Message-ID: <40FE562C.6070800@peshkin.net> Jeroen Ruigrok/asmodai wrote: >-On [20040721 08:02], Joel Peshkin (bugreport at peshkin.net) wrote: > > >>I think this is a good idea, but we need a way to automatically pull >>those notes and compile them. >> >> > >Prefix each post with a subject of [RELNOTES:] ? > > > The problem is figuring out which is the final draft. This could be done by using an attachment for the relnotes text and using either an additional flag or a special filename/mime-type/desscription in conjuction with the existing flags to contain the RELNOTES. We would need some fancy tools to pull and assemble the appropriate attachments from the appropriate bugs, but it could be well worth it. For example, we could create a report (concatentated relnotes) from all the bugs found in a particular bonsai query or from all the bugs in a particular buglist. From kiko at async.com.br Wed Jul 21 12:55:32 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 21 Jul 2004 09:55:32 -0300 Subject: Proposal: Start requiring "code release notes" on a bug-level basis In-Reply-To: <40FE00D5.5070806@mikrobitti.fi> References: <40FE00D5.5070806@mikrobitti.fi> Message-ID: <20040721125532.GB685@async.com.br> On Wed, Jul 21, 2004 at 08:36:21AM +0300, Jouni Heikniemi wrote: > Yet, that code may change pretty familiar interfaces and ways to do > everyday coding. I'm thinking if updating the Developer Guide isn't what's missing -- what do you think? > This is why I think we should have "release notes" for significant > changes to the codebase. These notes would be posted to developers@ at > the time of checkin, and they should describe the new feature and the > implications in the code. When I was aware Erik had started working on the Auth:: redesign that landed yesterday, I offered to write a small spec which now lives in Bugzilla/Auth/README. This is still very rough, but I mean to update it to reflect whatever's the "current" way of authentication. I could have circulated this through developers, but didn't. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From gerv at mozilla.org Wed Jul 21 22:18:09 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 21 Jul 2004 23:18:09 +0100 Subject: Proposal: Start requiring "code release notes" on a bug-level In-Reply-To: <40FE00D5.5070806@mikrobitti.fi> References: <40FE00D5.5070806@mikrobitti.fi> Message-ID: <40FEEBA1.9030103@mozilla.org> Jouni Heikniemi wrote: > Processwise, I think approval should be withheld until there is an > acceptable proposal for notes available in the bug. It's then finally up > to the approver to decide whether information about a certain change > should be posted to developers at . It should be the responsibility of the > person doing the checkin to make sure the notes actually get posted. Sounds very sensible. But I don't think we should confuse this with actual user-facing release notes. A note to developers@ making them aware of the change and telling them of the impact on them would be very different to a note suitable for publication in user-facing release notes. I say we do the former, but let the latter be compiled at release time, as normal (perhaps using the former as source material.) Gerv From jth at mikrobitti.fi Thu Jul 22 05:21:51 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Thu, 22 Jul 2004 08:21:51 +0300 Subject: Proposal: Start requiring "code release notes" on a bug-level In-Reply-To: <20040721125532.GB685@async.com.br> References: <40FE00D5.5070806@mikrobitti.fi> <20040721125532.GB685@async.com.br> Message-ID: <40FF4EEF.40901@mikrobitti.fi> Christian Robottom Reis wrote: > I'm thinking if updating the Developer Guide isn't what's missing -- > what do you think? I think updating the Dev guide is parallel to this. We _need_ to have that updated as well, but which of you guys ever even take a quick glance at it? My point is, DevGuide is (should be) a reference and a tutorial, but it's not a newsfeed that lets you keep your Bugzilla-specific coding knowledge up-to-date. If information about essential codebase updates were sent to this list, the person in charge of updating the devguide could fairly easily spot bigger issues just by reading developers at . This way, the regular developer information posted would also benefit the process of keeping devguide up to date. It was a bad idea to even start using the term "release notes" in this discussion. I didn't come up with anything better and I still don't have a good idea, but it is confusing. Gerv is right: user-wise relnotes should be different and apart from this. If we don't group this "code knowledge" by release (which is fine, if we integrate it into devguide anyway), we don't have to find a way to automatically collect the information either. Jouni From jpyeron at pdinc.us Thu Jul 22 13:40:54 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Thu, 22 Jul 2004 09:40:54 -0400 (EDT) Subject: Proposal: Start requiring "code release notes" on a bug-level In-Reply-To: <40FF4EEF.40901@mikrobitti.fi> Message-ID: change notes. We keep a database of them. If an engineer needs to change something, they submit a change request, then they get a change approval, then the team get the change notes. The change notes are formatted like so: When : The date What : list of spec/function which were changed Where : list of modules touched by change How : what types of change Who : list of engineers, who did the change THEMSELVES Summary : free text Ex: When : 9:33 7/22/2004 What : none Where : power line condition module How : Part substitution Who : Bob Smith, Jane Doe Summary : The 0.01 nano farad capacitor costs too much. For C32, we are now using a 0.02 nano farad capacitor. Ex: When : 9:34 7/22/2004 What : return value Where : fibinachi function How : code logic Who : Bob Smith Summary : The fibinachi function should return 0 up to and until 0, we don't want it to return negative numbers. if (idx<0) idx=0; On Thu, 22 Jul 2004, Jouni Heikniemi wrote: > It was a bad idea to even start using the term "release notes" in this > discussion. I didn't come up with anything better and I still don't have > a good idea, but it is confusing. Gerv is right: user-wise relnotes > should be different and apart from this. If we don't group this "code > knowledge" by release (which is fine, if we integrate it into devguide > anyway), we don't have to find a way to automatically collect the > information either. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Partner & Sr. Manager Pyerotechnics Development, Inc. - - +1 (443) 451-2697 500 West University Parkway #1S - - +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 bugreport at peshkin.net Thu Jul 22 15:25:08 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 22 Jul 2004 08:25:08 -0700 Subject: Accessibility and Bugzilla Message-ID: <40FFDC54.9010305@peshkin.net> All: After playing with the developers toolbar, the question of accessibility for the disabled piqued my interest. We do not appear to be very far off right now. Many of the practices we use just for good w3c validation and compatibility get us about 90% of the way to passing accessibility checks. This represents an opportunity to continue to differentiate Bugzilla. I am considering pushing towards passing the disabled access audits for 2.20. Should we take that on?? There is a fine tutorial at http://www.jimthatcher.com/webcourse1.htm and I believe that the biggest impact to the Bugzilla code is descibed in http://www.jimthatcher.com/webcourse8.htm By and large, it seems that the biggest change is we would need to change... Foo: to : and we would have to make sure we add alt tags to all graphics (the purely decorative ones get alt="") Please comment. -Joel From asmodai at wxs.nl Thu Jul 22 15:38:57 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Thu, 22 Jul 2004 17:38:57 +0200 Subject: Accessibility and Bugzilla In-Reply-To: <40FFDC54.9010305@peshkin.net> References: <40FFDC54.9010305@peshkin.net> Message-ID: <20040722153857.GW1768@nexus.ninth-circle.org> -On [20040722 17:32], Joel Peshkin (bugreport at peshkin.net) wrote: >There is a fine tutorial at http://www.jimthatcher.com/webcourse1.htm >and I believe that the biggest impact to the Bugzilla code is descibed >in http://www.jimthatcher.com/webcourse8.htm I'm fond of: http://diveintoaccessibility.org/ Which details actual user cases. -- Jeroen Ruigrok van der Werven / asmodai / kita no mono Free Tibet! http://www.savetibet.org/ | http://www.tibet.nu/ http://www.tendra.org/ | http://diary.in-nomine.org/ A friend is a single soul dwelling in two bodies... From Kamal.Ahmed at esecurity.net Thu Jul 22 15:37:42 2004 From: Kamal.Ahmed at esecurity.net (Kamal Ahmed) Date: Thu, 22 Jul 2004 11:37:42 -0400 Subject: E-mail not being sent for bugs Message-ID: <5513C07DE400274F9D90FF87B861873F35144F@va-ex01> Hi All, I have a bugzilla installation, and found out the a lot of bug notifications were not being sent to bug owners, and admins. When I ran http://bugzilla.esecurityinc.com/sanitycheck.cgi , I found that there were 1000 unsent mail, now If I run "processmail rescanall" I will flood our MS Exchange , is there a way out of this situation ? Thanks, -Kamal. From gerv at mozilla.org Thu Jul 22 19:31:28 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 22 Jul 2004 20:31:28 +0100 Subject: Accessibility and Bugzilla In-Reply-To: <40FFDC54.9010305@peshkin.net> References: <40FFDC54.9010305@peshkin.net> Message-ID: <41001610.7000500@mozilla.org> Joel Peshkin wrote: > > All: > > After playing with the developers toolbar, the question of > accessibility for the disabled piqued my interest. We do not appear to > be very far off right now. Many of the practices we use just for good > w3c validation and compatibility get us about 90% of the way to passing > accessibility checks. > > This represents an opportunity to continue to differentiate Bugzilla. > I am considering pushing towards passing the disabled access audits for > 2.20. Should we take that on?? > > There is a fine tutorial at http://www.jimthatcher.com/webcourse1.htm > and I believe that the biggest impact to the Bugzilla code is descibed > in http://www.jimthatcher.com/webcourse8.htm > > By and large, it seems that the biggest change is we would need to > change... Actually, quite a bit of this is done - someone went on a spree a while ago, although I don't know how extensive it was. > and we would have to make sure we add alt tags to all graphics (the > purely decorative ones get alt="") Do we have any that _aren't_ purely decorative? OK, we have dep graphs and charts, but you can't really describe their contents in text. Gerv From myk at mozilla.org Fri Jul 23 00:47:37 2004 From: myk at mozilla.org (Myk Melez) Date: Thu, 22 Jul 2004 17:47:37 -0700 Subject: Bugzilla CSS plan Message-ID: <41006029.1070305@mozilla.org> Bugzilla is being converted to structural HTML and stylistic CSS for both skinnability and customizability , and we need a CSS plan that works for both. Here's what I'm thinking: ------------------------------------------------------------------------ We move the Bugzilla CSS files, which currently live in css/, to skins/default/. We style all Bugzilla pages with skins/default/global.css, and we style pages needing special styling with page-specific files named after the page they style (f.e. skins/default/buglist.css). [Why move from css/ to skins/? Because modern CSS often includes images, and we need to store them somewhere, and it'll be much easier to install skins into a single directory instead of breaking out the stylesheet and image files, and "css" is misleading if we're storing images there too.] checksetup.pl creates a skins/custom/ directory. We add notes to the skins/default/ files telling customizers to override default rules by putting them into the equivalent files in skins/custom/. We also point out that customizers can put all their rules, including page-specific rules, into the single file skins/custom/global.css to make things easier. We give all body tags page-specific IDs to make this possible. We add a caveat about the performance cost of this approach. checksetup.pl creates a skins/other/ directory. We tell installation admins who want to add skins as alternate stylesheets to put them into this directory. Skins can be either a single file named skins/other/.css or a directory of files named skins/other//. The of the file/directory will be the title of the alternate stylesheet. [Why make checksetup create the skins/custom/ and skins/other/ directories? Because we don't want them managed by CVS, since that complicates the output of "cvs diff".] Bugzilla automatically adds custom and alternate stylesheets to pages via a template plugin that trawls skins/custom/ and skins/other/ and provides a list of available custom/alternate stylesheets to header.html.tmpl. header.html.tmpl generates persistent stylesheet tags for custom stylesheets, preferred stylesheet tags with the title "standard" for default stylesheets, and alternate stylesheet tags with the titles "" for other stylesheets. Thus pages take on the default style, as modified by custom styles, until the user selects an alternate style, whereupon they take on the default style, as modified by custom styles. More on persistent, preferred, and alternate stylesheets: http://www.w3.org/TR/html4/present/styles.html#h-14.3.1 http://www.alistapart.com/articles/alternate/ Installations admins can choose a different default skin via a parameter, in which case the skin they choose becomes the preferred stylesheet. Portions of this proposal that can be usefully implemented independently should be. ------------------------------------------------------------------------ Thoughts? -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From jth at mikrobitti.fi Fri Jul 23 04:55:41 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Fri, 23 Jul 2004 07:55:41 +0300 Subject: Accessibility and Bugzilla In-Reply-To: <40FFDC54.9010305@peshkin.net> References: <40FFDC54.9010305@peshkin.net> Message-ID: <41009A4D.4080302@mikrobitti.fi> Joel et al., > After playing with the developers toolbar, the question of > accessibility for the disabled piqued my interest. We do not appear to > be very far off right now. Many of the practices we use just for good > w3c validation and compatibility get us about 90% of the way to passing > accessibility checks. Accessibility is one of the more controversial topics around in web development. I worked for Finnish state for a year, and pushing accessibility knowledge was one of my tasks at the time. Every project and initiative aimed at taking accessibility into account was almost doomed to fail, unless the level of accessibility desired was defined and decided on prior to starting. For simple information sites with little HTML functionality, it's quite ok to state the aim as "We want W3C AAA accessibility" or "Let's match Section 508 criteria". But when it comes to a heavy specialist information app like Bugzilla, a little more thought is necessary. Do we _really_ want screen reader support? While I agree it is a socially responsible direction to move to, do we have sufficient knowledge and determination to keep things that way, once the current structures are changed to match some set of standards? Also, from a practical viewpoint, would matching 508 (or WAI AAA for that matter) in Bugzilla be truly useful? Just as an example: One of the more vague rules of accessibility is using simple language. Most of Bugzilla installations use _very_ complex language, and even our default templates are pretty tough by themselves. True accessibility (as opposed to spec compatibility - though they may be close to one another at times) is a web app thing, not an HTML thing. MIME Types, requestees and all that stuff is tough to comprehend even for a person with a "normal" set of senses and brain functions. Throw in a visually impaired person with dyslexia, and I don't think adding some