From bugreport at peshkin.net Tue Oct 1 03:04:01 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 30 Sep 2002 20:04:01 -0700 Subject: Names that stink less Message-ID: <3D9910A1.7060609@peshkin.net> All: http://bugzilla.mozilla.org/show_bug.cgi?id=147275 defines 6 relationships that a product and a group can have to each other. By popular consensus, the current names stink, but nobody has been able to suggest names that stink less. Please suggest names for the 6 relationships here.... None Bugs in this product are never associated with this group. Permitted Bugs in this product are permitted to be restricted to this group. Users who are a member of this group will be able to place bugs in this group. Open Bugs in this product can be placed in this group by anyone with permission to edit the bug even if they are not a member of this group. WeakDefault Bugs in this product are permitted to be restricted to this group and are placed in this group by default.Users who are a member of this group will be able to place bugs in this group. StrongDefault Bugs in this product are permitted to be restricted to this group and are placed in this group by default.Users who are a member of this group will be able to place bugs in this group. Users who are not members of this group will not be given an option to override the default. Required Bugs in this product are required to be restricted to this group. Users are not given any option. None becomes: Permitted becomes: Open becomes: WeakDefault becomes: StrongDefault becomes: Required becomes: From gerv at mozilla.org Tue Oct 1 07:33:48 2002 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 01 Oct 2002 08:33:48 +0100 Subject: Names that stink less References: <3D9910A1.7060609@peshkin.net> Message-ID: <3D994FDC.8000903@mozilla.org> > WeakDefault Bugs in this product are permitted to be restricted to this > group and are placed in this group by default.Users who are a member of > this group will be able to place bugs in this group. > StrongDefault Bugs in this product are permitted to be restricted to > this group and are placed in this group by default.Users who are a > member of this group will be able to place bugs in this group. Users who > are not members of this group will not be given an option to override > the default. Do these only relate to bug creation, or do they also relate to bug editing? Is the only difference between Open and WeakDefault that WeakDefault is checked by default at bug entry? These three are hard (consider these names a work in progress): > Open becomes: UniversallyAssignable > WeakDefault becomes: GroupAssignable > StrongDefault becomes: ? These two are mutually exclusive, yes? StrongDefault only makes sense for bugs also marked Open, right? I'm reasonably confident about these three: > None becomes: Forbidden > Permitted becomes: Permitted > Required becomes: Mandatory These three are mutually exclusive, yes? Gerv From gerv at mozilla.org Fri Oct 4 07:07:53 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 04 Oct 2002 08:07:53 +0100 Subject: Non-specific templates Message-ID: <3D9D3E49.4040900@mozilla.org> global/field-descs.html.tmpl contains no output. All it does it define a mapping hash for you. Should it be an "html" template? If not, what ctype should it be using? "xxx"? "none"? Gerv From justdave at syndicomm.com Sat Oct 5 04:01:20 2002 From: justdave at syndicomm.com (David Miller) Date: Sat, 5 Oct 2002 00:01:20 -0400 Subject: Bugzilla in the ADC News Message-ID: Bugzilla got a mention in the Apple Developer news this week... http://developer.apple.com/devnews/ See item #12 -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From bbaetz at student.usyd.edu.au Mon Oct 7 04:04:13 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Mon, 7 Oct 2002 14:04:13 +1000 (EST) Subject: require 5.006 Message-ID: What do people thing about requiuring perl 5.6? The reason for wanting this is perl 5.005's interaction with TT, where any tainted variable causes all the vars to become tainted. I never did trace this down, but since noone else wants to do so either... The problem this causes is that [% PROCESS foo/edit-$format.html.tmpl %] won't work, because the vars hash containts tainted elements (like $::ENV{'HTTP_USER_AGENT'}), so $foo is tainted, so the process fails. This happened in bug 160170. See bug 160710 comment 21 for a more detailed explination, but basically, with TT < 2.08, this was just inefficient (because the template was recompiled each time), but with TT 2.08, it compiles to a temp file, and then renames. Rename checks to taintednes for the file you're going to overwrite, and so this fails. AFAIK, none of the developers have 5.005 (except for the install on landfill), and so its possible other 5.005 bugs will exist. Thoughts? Bradley From kiko at async.com.br Mon Oct 7 18:36:30 2002 From: kiko at async.com.br (Christian Reis) Date: Mon, 7 Oct 2002 15:36:30 -0300 Subject: require 5.006 In-Reply-To: ; from bbaetz@student.usyd.edu.au on Mon, Oct 07, 2002 at 02:04:13PM +1000 References: Message-ID: <20021007153630.F6694@blackjesus.async.com.br> On Mon, Oct 07, 2002 at 02:04:13PM +1000, Bradley Baetz wrote: > The reason for wanting this is perl 5.005's interaction with TT, where any > tainted variable causes all the vars to become tainted. I never did trace > this down, but since noone else wants to do so either... I have 5.005 on anthem, so I could help out. > AFAIK, none of the developers have 5.005 (except for the install on > landfill), and so its possible other 5.005 bugs will exist. I'm fine with upgrading perl here, so if you think it's too much work to be done, go for it. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From myk at mozilla.org Mon Oct 7 20:23:00 2002 From: myk at mozilla.org (Myk Melez) Date: Mon, 07 Oct 2002 13:23:00 -0700 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> <3D94E6F7.3050803@peshkin.net> <3D95164D.8020309@mozilla.org> <3D960BED.80605@peshkin.net> Message-ID: <3DA1ED24.90802@mozilla.org> Joel Peshkin wrote: > Myk Melez wrote: > >> >> I suspect not. Although that bug is the right approach for >> tech-saavy users and installations with large groups of potential >> assignees (like b.m.o), pull-down menus with visible choices and no >> way to enter a wrong value are much easier to use. >> > Point taken on the ease of use, but I found that it only took about > 100 users before drop-downs started getting clunky and making the > tech-saavy users wish for wildcards. (or substrings) Agreed, but I think in this case every bug will only have a small number of potential assignees, since each development group will be responsible for bugs in its product (which is fundamentally different from an open source organization where anyone could potentially fix a bug anywhere in the code). The trick will be how to define these small groups of people (per product/component/sub-component?) and how to handle exceptions. -myk From myk at mozilla.org Mon Oct 7 20:32:28 2002 From: myk at mozilla.org (Myk Melez) Date: Mon, 07 Oct 2002 13:32:28 -0700 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> <3D9514AF.4080103@mozilla.org> <3D961961.8040200@mozilla.org> Message-ID: <3DA1EF5C.3030408@mozilla.org> Gervase Markham wrote: > Myk Melez wrote: > >> Gervase Markham wrote: >> >>> What sort of timeframe is Zippy looking at to get all these >>> enhancements made? >> >> >> The schedule isn't in place yet, but current thinking is to finish >> development and get everyone using the system by May/June of next >> year, with periodic deployments before then to groups willing to use >> a moving target. > > > How many developers are they planning to commit? One or two, plus some consultants (like me). -myk From bugreport at peshkin.net Mon Oct 7 20:36:34 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 07 Oct 2002 13:36:34 -0700 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> <3D94E6F7.3050803@peshkin.net> <3D95164D.8020309@mozilla.org> <3D960BED.80605@peshkin.net> <3DA1ED24.90802@mozilla.org> Message-ID: <3DA1F052.3010700@peshkin.net> Myk Melez wrote: > > Agreed, but I think in this case every bug will only have a small > number of potential assignees, since each development group will be > responsible for bugs in its product (which is fundamentally different > from an open source organization where anyone could potentially fix a > bug anywhere in the code). > > The trick will be how to define these small groups of people (per > product/component/sub-component?) and how to handle exceptions. > > -myk > > So we have a few issues to beat up. Potential assignees works for assigned fields, but CC is harder. (see bug 145499). Perhaps the logic for bug 147275 can be extended. -Joel From myk at mozilla.org Mon Oct 7 20:58:13 2002 From: myk at mozilla.org (Myk Melez) Date: Mon, 07 Oct 2002 13:58:13 -0700 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> <3D94E6F7.3050803@peshkin.net> <3D95164D.8020309@mozilla.org> <3D960BED.80605@peshkin.net> <3DA1ED24.90802@mozilla.org> <3DA1F052.3010700@peshkin.net> Message-ID: <3DA1F565.6000201@mozilla.org> Joel Peshkin wrote: > Potential assignees works for assigned fields, but CC is harder. (see > bug 145499). Perhaps the logic for bug 147275 can be extended. I think it's OK to implement this feature just for the assignee and QA contact fields. Those are the fields likely to be restricted to a small group of people in a traditional development organization, while CC: is by definition an ambiguous, whoever-is-interested type field. -myk From gerv at mozilla.org Mon Oct 7 21:25:10 2002 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 Oct 2002 22:25:10 +0100 Subject: corporate win--their requirements In-Reply-To: <3D948D32.1020509@mozilla.org> References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> <3D94E6F7.3050803@peshkin.net> <3D95164D.8020309@mozilla.org> <3D960BED.80605@peshkin.net> <3DA1ED24.90802@mozilla.org> Message-ID: <3DA1FBB6.5030504@mozilla.org> Myk Melez wrote: > Agreed, but I think in this case every bug will only have a small number > of potential assignees, since each development group will be responsible > for bugs in its product (which is fundamentally different from an open > source organization where anyone could potentially fix a bug anywhere in > the code). > > The trick will be how to define these small groups of people (per > product/component/sub-component?) and how to handle exceptions. I'm with Myk - I think that Bugzillas where a bug in a product has hundreds of potential assignees will be the exception rather than the rule. Obviously, we should provide a way to turn this off and go back to text boxes for those sites. I would lean towards having the list as everyone who is a member of that product's group. (As a side note, I think it's high time we moved the field where you edit the assignee up into the main body of the bug, where the current text version of that field is, rather than down in the knob.) Gerv From justdave at syndicomm.com Mon Oct 7 21:31:48 2002 From: justdave at syndicomm.com (David Miller) Date: Mon, 7 Oct 2002 17:31:48 -0400 Subject: corporate win--their requirements In-Reply-To: <3DA1FBB6.5030504@mozilla.org> References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> <3D94E6F7.3050803@peshkin.net> <3D95164D.8020309@mozilla.org> <3D960BED.80605@peshkin.net> <3DA1ED24.90802@mozilla.org> <3DA1FBB6.5030504@mozilla.org> Message-ID: On 10/7/02 10:25 PM +0100, Gervase Markham wrote: > (As a side note, I think it's high time we moved the field where you > edit the assignee up into the main body of the bug, where the current > text version of that field is, rather than down in the knob.) I agree. :-) Doing that would automatically fix most of the "reassign and do xyz at the same time" bugs, too :-) -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From sergeyli at pisem.net Mon Oct 7 16:09:18 2002 From: sergeyli at pisem.net (Sergey A Lipnevich) Date: Mon, 07 Oct 2002 12:09:18 -0400 Subject: Storing localconfig and data/ one level up from Bugzilla home Message-ID: Hi! I'm new to Bugzilla development. For the purpose of having multuple Bugzilla repositories on the same system reusing same source code, I adjusted Bugzilla to use localconfig and data/ information located one level *above* Bugzila home, like this: /projectA/config/bugzilla/localconfig /projectA/config/bugzilla/data/... /projectA/config/bugzilla/cgi -> symlink to /usr/share/bugzilla where the actual code is /projectB/config/bugzilla/localconfig /projectB/config/bugzilla/data/... /projectB/config/bugzilla/cgi -> symlink to /usr/share/bugzilla This way, globals.pl located localconfig and data/ and sets several global variables to point at relevant files/directories. All other Bugzilla modules are reusing these variables instead of having them hard-coded. Things like database info and data/params are then different for each repository, while source code is the same. I also have modified necessary parts to use perl-ldap (see http://search.cpan.org/author/GBARR/perl-ldap-0.26/) for authentication. It now more or less works with my OpenLDAP 2.1.5. The version of Bugzilla used was 2.16.0. If you are interested in including such functionality into the mainstream Bugzilla, I could prepare and send my patches. Finally, I wanted to say many thanks to the development team for the terrific product! Regards, Sergey. From gerv at mozilla.org Tue Oct 8 21:55:47 2002 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 08 Oct 2002 22:55:47 +0100 Subject: require 5.006 In-Reply-To: References: <20021007153630.F6694@blackjesus.async.com.br> Message-ID: <3DA35463.60707@mozilla.org> Christian Reis wrote: >>AFAIK, none of the developers have 5.005 (except for the install on >>landfill), and so its possible other 5.005 bugs will exist. > > I'm fine with upgrading perl here, so if you think it's too much work to > be done, go for it. 5.6 was released on Tue, 28 Mar 2000. http://archive.develooper.com/perl-release-announce at perl.org/msg00004.html That's 2 1/2 years ago. So I think it's fair to require it. Post to the newsgroup; if no-one steps up to the plate to fix 5.005 issues, then we'll switch. On a related note, are we going to move to TT 2.08a, because of bug 126955? http://bugzilla.mozilla.org/show_bug.cgi?id=126955 Gerv From gerv at mozilla.org Tue Oct 8 21:58:09 2002 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 08 Oct 2002 22:58:09 +0100 Subject: Storing localconfig and data/ one level up from Bugzilla home In-Reply-To: References: Message-ID: <3DA354F1.5090301@mozilla.org> Sergey A Lipnevich wrote: > The version of Bugzilla used was 2.16.0. If you are interested in > including such functionality into the mainstream Bugzilla, I could > prepare and send my patches. If it's not too much effort, that would be great. Please file bugs in bugzilla.mozilla.org for each different chunk of function, and attach the relevant patch (diff -u). There's a possibility that they'll just sit there for a long time (that's happened with a few good patches), but that would be our fault for not taking the offered opportunity. :-| Gerv From tobias.burnus at physik.fu-berlin.de Tue Oct 8 22:07:11 2002 From: tobias.burnus at physik.fu-berlin.de (Tobias Burnus) Date: Wed, 9 Oct 2002 00:07:11 +0200 (CEST) Subject: require 5.006 In-Reply-To: <3DA35463.60707@mozilla.org> Message-ID: Hi, On Tue, 8 Oct 2002, Gervase Markham wrote: > On a related note, are we going to move to TT 2.08a, because of bug 126955? > http://bugzilla.mozilla.org/show_bug.cgi?id=126955 I think it works with TT 2.08. Only DEBUG is completely broken in TT 2.08a. I reversed to 2.08 and it still seems to work. I guess this was due to some error which I only detected after DEBUG was working. Thus: TT 2.08 should be ok for running, for developing TT 2.08a is definitly better. Tobias PS: Could someone review the patch? (Which only requires TT 2.08 in checksetup.) http://bugzilla.mozilla.org/show_bug.cgi?id=bz-l10n From bbaetz at student.usyd.edu.au Mon Oct 14 13:57:50 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Mon, 14 Oct 2002 23:57:50 +1000 (EST) Subject: Error handling in bugzilla Message-ID: Currently, bugzilla uses CGI::Carp to report/log errors. This has a number of problems: a) Newer versions of CGI::Carp override CORE::GLOBAL::die rather than using $::SIG{__DIE__} (to better work with mod_perl). The problem is that for this to work, it must happen at compile time, but we bring this in at runtime (via require), so it doesn't work for anything compiled before CGI::Carp is brought in. This is mostly unnoticed, since we don't use die directly in our .cgis, but we may do so via an intermediate |use| b) This only applies to CGIs (hence the name). This is why we get the errorlog style error messages from checksetup if the error occurs afer globals.pl is brought in, or we did when CGI::Carp used the $::SIG{__DIE__} version, anyway. c) It doesn't work with mod_perl. Both forms of the die stuff happen even if we're in an eval. This was the cause of the File::Find/File::Temp issue which people were having - File::Temp tried to get some comnstants which didn't always exist, so it used an eval. But CGI::Carp caught the die, and exited it, before the eval could work. Newer CGI::Carp versions work arround this by checkinbg $^S, and doing nothing if we were in an eval. mod_perl code runs in an eval, so it doens't work. Even newer versions of CGI::Carp try to work arround this too. They do this by constructing a backtrace (via Carp, effectively), and checking if the _text_ looks mod_perlish, by |=~ /eval [\{\']/m|. d) It only works with CGIs. It doesn't work with commandline programs, mailed in stuff, or xmlrpc. Fundamentally, it can't. e) The code relies on a global variable, $::vars->{header_done}. mod_perl doesn't like global vars. OK, in this case its easy to fix, but since we already have a Bugzilla::CGI class (or will RSN), and it knows if we've sent anything, it makes sense to use that. Plus, only 1.5 scripts (the buglist.cgi usage is almost certainly incorrect) use it, and we're going to rewrite process_bug anyway, right? :) So I'd like to propose a new way of doing this. For motivation, see http://axkit.org/docs/presentations/tpc2001/exceptions.axp/a.pdf (and the 2002 version of the same) Basic idea: - all errors, of any sort, are handled as exceptions. - Said exceptions are Exception::Class subclasses, probably. - die calls from other, non-bugzilla modules are made into objects via a CORE::GLOBAL::die handler (see the above pdf for an example) - throw{user,code}error become exceptions, whose 'what do I do to ouput as html' method becomes a call to TT. See the patch for how this (roughly) will work. This has the advantage that they're catchable, so we could do stuff like run a set of queries, without dying on the first invalid one, and so on. - all scripts are wrapped in an eval block, with a postscript of: if ($@) { Bugzilla::CGI->HandleError($@); } or something like that, anyway. (Actually, probably $cgi->handle_error($@) instead). This is the ugly part, but we can't really do anything else, and still handle mod_perl. - Plain text errors are handled by rearranging the {user,code}-error.html.tmpl stuff so that it can be used from a .txt, too. This is something to be done in teh future, not something I want to do now. Its not quite as simple as that, because we need to work arround some perl bugs. The first affects the debug output from TT, and affects all versions of perl, when using CORE::GLOBAL::die to do this - see http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-09/msg01204.html I've made a patch to fix TT - see http://template-toolkit.org/pipermail/templates/2002-October/003779.html This only affects TT's error cases, though, making the error message useless/uninformative/etc. This is fixed in perl-5.9-devel, but the only workarround is to use $SIG{__DIE__} instead, or to use extra brackets in the die statement. The second bug only affects perl 5.8, using $SIG{__DIE__}. Exception objects are stringified, making them basically useless. See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-10/msg00271.html, which hasn't yet been dealt with. The work arround for this is to use CORE::GLOBAL::die. So we have two almost mutually exclusive workarrounds, which leads to the above TT patch being required. Ain't perl fun.... I've attached a really really really hacky patch to bug 173626. It doesn't do the eval thing, or the compile time thing (ie, it doesn't actually work). It has lots of XXX comments, with things which may/should change. That code assumes that we can get this to work (at least for the moment) w/o the eval-round-each-script thing. I'm not convinced that this is the case any more, though, or that we should try. The other thing is that if Bugzilla::Template reports errors via Bugzilla::Exception, but Bugzilla::Exception uses tempalates for format the error, then we have a circular dependancy.... The fix for this is probably to not have Bugzilla::Exception objects use templates at all, but rather define all the exceptions so that they have a template name/tag which we can then process in Bugzilla::CGI/Bugzilla::xmlrpc/etc. I think that thats the best way, but I haven't thought it through entirely Thoughts? Bradley From gerv at mozilla.org Mon Oct 14 22:52:18 2002 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 14 Oct 2002 23:52:18 +0100 Subject: Changes to default search options Message-ID: <3DAB4AA2.1030600@mozilla.org> Analysis of the "This query was killed for taking too long" logs on bugzilla.mozilla.org, which give a good indication of which queries people are running that take up a lot of resources, leads me to suggest the following changes to bugzilla.mozilla.org's default search options. The question is, do we make these to Bugzilla, the software, as well? - Default email searches to "exact match" http://bugzilla.mozilla.org/show_bug.cgi?id=173567 Exact match searches are far less resource-intensive, and evidence from the logs shows that people are typing in full email addresses and doing substring searches, which is silly. If we default to exact, and they type in a substring and search, they get Zarro, quickly, and adjust their parameters. Better that than the other way round. - Default text search boxes to "contains string" http://bugzilla.mozilla.org/show_bug.cgi?id=173689 People often type in a string like "unable to close dialog" to search the comments for, and then hit "Search"; the current default returns a list of all bugs with at least one comment with any of those four words in. As well as being useless, this is very time-consuming. - Pre-select Browser and MailNews http://bugzilla.mozilla.org/show_bug.cgi?id=173573 (This also requires a priority sorting of the product list on the search page.) This default selection will a) be what most people want, b) reduce the number of bugs that are searched by default, c) produce more sensible initial default component and milestone lists. (This one is obviously b.m.o.-only.) In all of these, the principle I am adopting is that we should default to an option which uses less resources. Your comments are welcome, both from a code and a usability perspective. Gerv From bugreport at peshkin.net Mon Oct 14 23:22:38 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 14 Oct 2002 16:22:38 -0700 Subject: Changes to default search options References: <3DAB4AA2.1030600@mozilla.org> Message-ID: <3DAB51BE.7030100@peshkin.net> Gervase Markham wrote: > > - Default email searches to "exact match" > http://bugzilla.mozilla.org/show_bug.cgi?id=173567 > Exact match searches are far less resource-intensive, and evidence > from the logs shows that people are typing in full email addresses > and doing substring searches, which is silly. If we default to exact, > and they type in a substring and search, they get Zarro, quickly, > and adjust their parameters. Better that than the other way round. > Perhaps the system should first search for users matching the string and then do the bug search for userid IN (list). ?? From bbaetz at student.usyd.edu.au Thu Oct 17 00:39:39 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 17 Oct 2002 10:39:39 +1000 (EST) Subject: l10n + custom fields Message-ID: How are we going to internationalise these (or anything where the description is part of the db)? I don't want to require admins to customise a template when the edit a field, but I don't think that storing umpteen languages in the db is the way to go, either. Thoughts? Bradley From justdave at syndicomm.com Thu Oct 17 00:43:12 2002 From: justdave at syndicomm.com (David Miller) Date: Wed, 16 Oct 2002 20:43:12 -0400 Subject: l10n + custom fields In-Reply-To: References: Message-ID: On 10/17/02 10:39 AM +1000, Bradley Baetz wrote: > How are we going to internationalise these (or anything where the > description is part of the db)? > > I don't want to require admins to customise a template when the edit a > field, but I don't think that storing umpteen languages in the db is the > way to go, either. > > Thoughts? The human-reable portion of FieldDefs should go away in favor of a template. Adding custom fields is not something someone's going to be doing every day. Asking someone to edit a template to compensate shouldn't be out of the question. If the template mapping doesn't provide an English (or whatever language) name for a field, we use the computer-readable name for it from fielddefs until they put it in the template. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From bbaetz at student.usyd.edu.au Thu Oct 17 00:49:09 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 17 Oct 2002 10:49:09 +1000 (EST) Subject: l10n + custom fields In-Reply-To: Message-ID: On Wed, 16 Oct 2002, David Miller wrote: > The human-reable portion of FieldDefs should go away in favor of a template. > Adding custom fields is not something someone's going to be doing every > day. Asking someone to edit a template to compensate shouldn't be out of > the question. If the template mapping doesn't provide an English (or > whatever language) name for a field, we use the computer-readable name for > it from fielddefs until they put it in the template. > I want to get rid of fielddefs entirely :) What about stuff like product/component descriptions? Or keyword/flag descriptions? Then again, for an installation which only supports one language (whatever that language may be), they can just write the description in that language. That may be the best solutionm. Bradley From justdave at syndicomm.com Thu Oct 17 00:53:59 2002 From: justdave at syndicomm.com (David Miller) Date: Wed, 16 Oct 2002 20:53:59 -0400 Subject: l10n + custom fields In-Reply-To: References: Message-ID: On 10/17/02 10:49 AM +1000, Bradley Baetz wrote: > On Wed, 16 Oct 2002, David Miller wrote: > >> The human-reable portion of FieldDefs should go away in favor of a template. >> Adding custom fields is not something someone's going to be doing every >> day. Asking someone to edit a template to compensate shouldn't be out of >> the question. If the template mapping doesn't provide an English (or >> whatever language) name for a field, we use the computer-readable name for >> it from fielddefs until they put it in the template. >> > > I want to get rid of fielddefs entirely :) Fielddefs is necessary because of the mapping in the activity table. :( Unless we make yet more schema changes to the activity table... > What about stuff like product/component descriptions? Or keyword/flag > descriptions? Then again, for an installation which only supports one > language (whatever that language may be), they can just write the > description in that language. That may be the best solutionm. Hmmm. Yeah, those are a bit much to template, because those will get changed more frequently. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From bbaetz at student.usyd.edu.au Thu Oct 17 01:01:59 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 17 Oct 2002 11:01:59 +1000 (EST) Subject: l10n + custom fields In-Reply-To: Message-ID: On Wed, 16 Oct 2002, David Miller wrote: > > I want to get rid of fielddefs entirely :) > > Fielddefs is necessary because of the mapping in the activity table. :( > Unless we make yet more schema changes to the activity table... Well, we need a mapping, thats true. What I meant to say was that I want to get rid of the current impl (the boolean for 'should display in mail for New bugs' is just Wrong) Bradley From eduardo.habiro at orbitall.com.br Wed Oct 16 20:27:17 2002 From: eduardo.habiro at orbitall.com.br (eduardo.habiro at orbitall.com.br) Date: Wed, 16 Oct 2002 17:27:17 -0300 Subject: doubt Message-ID: please,i'm starting installing bugzilla in windows, what i want to know is the mail of someone who has already installed on windows, and how long it takes to install if i'm not used to use perl,and mysql... thanks! _________________________ Eduardo Ikeda e Habiro HS - 12? andar - 3067 9110 eduardo.habiro at orbitall.com.br --------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From matty at chariot.net.au Thu Oct 17 05:29:05 2002 From: matty at chariot.net.au (MattyT) Date: 17 Oct 2002 14:59:05 +0930 Subject: l10n + custom fields In-Reply-To: References: Message-ID: <1034832546.811.11.camel@megagerbil> On Thu, 2002-10-17 at 10:19, Bradley Baetz wrote: > What about stuff like product/component descriptions? Or keyword/flag > descriptions? Then again, for an installation which only supports one > language (whatever that language may be), they can just write the > description in that language. That may be the best solutionm. I've been thinking about this somewhat, and I initially had the same reservations as you about the two approaches. However, the more I think about it, the more I'm convinced that putting the translations into the database is the way to go. This would involve a subsidiary table for name and description of keywords, groups, etc. A "default" name and description could probably still sit on the main table for the case nothing matches. The performance issue I don't believe is major, on the proviso that our target databases support compound primary keys (I don't know if they do, I hope so), which would be on value-ID/language. In this situation you need to do an extra join, but it's a simple index lookup. If you want to support locales within languages, then that's a bit more complicated, I think it would either need to be a subselect using LIMIT (to select the most appropriate record), or alternatively two joins, one against the language (although this could return multiple records too I suppose), and one against the language/locale. I have a hard time believing this is an area we have performance problems anyway, and we already have a caching solution (versioncache) to negate the effects of slow queries. If we stick with versioncache there would need to be a different one for each language, but that's pretty easily done. If we don't, and this is a performance hit, whatever future caching solution we use should be able to deal with it. And as for the extra complexity it would add to queries, this should not be a problem if we add functionality to the eventual back end API to transparently generate the appropriate SQL and return the correct results. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From gerv at mozilla.org Thu Oct 17 06:35:36 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Oct 2002 07:35:36 +0100 Subject: l10n + custom fields In-Reply-To: References: Message-ID: <3DAE5A38.1020803@mozilla.org> Bradley Baetz wrote: > On Wed, 16 Oct 2002, David Miller wrote: > > > >The human-reable portion of FieldDefs should go away in favor of a > template. > >Adding custom fields is not something someone's going to be doing every > >day. Asking someone to edit a template to compensate shouldn't be out of > >the question. If the template mapping doesn't provide an English (or > >whatever language) name for a field, we use the computer-readable > name for > >it from fielddefs until they put it in the template. Agreed. > What about stuff like product/component descriptions? Or keyword/flag > descriptions? Then again, for an installation which only supports one > language (whatever that language may be), they can just write the > description in that language. That may be the best solutionm. The only other option I can see here is to get them to use some sort of "encoding" in the edit box, which we then find and extract, e.g.: lang_en="A product for Foos"lang_fr="Un produit pour les Foos" etc. But that's a fairly nasty hack. Of all the l10n problems we have, this one's pretty minor. The major remaining issue is mail templatisation, which is waiting for JP to actually finish the patch in 84876 before anything else can be done. Gerv From gerv at mozilla.org Thu Oct 17 07:04:40 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Oct 2002 08:04:40 +0100 Subject: enter_bug page Message-ID: <3DAE6108.4040500@mozilla.org> We need to decide what is, and isn't going to be on the default enter_bug page. Until post_bug and process_bug are combined, at which point enter_bug can contain any fields that the admin desires, we have the problem that everything on the enter_bug screen requires duplicated code. It is also the case that we want to avoid over-complicating this screen - for example, the add-attachment interface is never going to appear there. We've been fending off suggestions ("Checkbox - vote for this bug") for a while now. It used to be the case that after you filed a bug, you had to click the link and wait for it to load before making any further changes. Now, the bug itself is output after the "bug added" message, so complaints in old bugs like "It is a multiple step process instead of one" no longer really apply. http://bugzilla.mozilla.org/show_bug.cgi?id=112373 has just been checked in, adding dependencies to the enter_bug page - this has resulted in a 400-line, 16k patch! And bug 112373 is the only bug I have ever seen requesting this feature - keywords, on the other hand, were requested by several people, the bug had 8 duplicates and it was an 80-line, 2k patch. http://bugzilla.mozilla.org/show_bug.cgi?id=25521 I think we should declare a moratorium on further complication of the enter_bug page (given the ease with which fields can be changed immediately after filing), and give serious consideration to backing out the dependencies patch. Thoughts? :-) Gerv From gerv at mozilla.org Thu Oct 17 07:10:53 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Oct 2002 08:10:53 +0100 Subject: Groups policy Message-ID: <3DAE627D.7060909@mozilla.org> We need to decide how, by default, we are going to restrict access to things. http://bugzilla.mozilla.org/show_bug.cgi?id=158353 proposes restricting the enter_bug page on b.m.o. to people with canconfirm; a counter-proposal says we should invent a new group. This raises the general question: is our policy by default to have a small number of groups on a increasing scale, like: (nothing, canconfirm, editbugs, editusers, "admin") and then fit each privilege onto it somewhere, or is it to create a new group for each thing ("canenterbugs" etc.) and ask admins to join their new users to all the groups they'd like them to have access to (either automatically using the regexp or by hand)? My view: I'm not claiming our current groups are the right names for the "increasing responsiblity scale" idea, but I think the principle is sound. Gerv From matty at chariot.net.au Thu Oct 17 07:43:17 2002 From: matty at chariot.net.au (MattyT) Date: 17 Oct 2002 17:13:17 +0930 Subject: Groups policy In-Reply-To: <3DAE627D.7060909@mozilla.org> References: <3DAE627D.7060909@mozilla.org> Message-ID: <1034840613.757.17.camel@megagerbil> On Thu, 2002-10-17 at 16:40, Gervase Markham wrote: > or is it to create a new group for each thing ("canenterbugs" etc.) > and ask admins to join their new users to all the groups they'd like > them to have access to (either automatically using the regexp or by > hand)? Avoiding this is the whole reason why the concepts of role and group should be separated, and the idea of "system groups" removed. If you have a group, you can say that group gets multiple roles. We have to think very carefully about tying roles together. Separate roles can be customised together, but tied roles cannot be split without code hacking. The existing system groups will hopefully be made into roles sometime before 2.18, but that doesn't mean we can't introduce new roles now. Indeed we did exactly that for insiders I believe. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From bbaetz at student.usyd.edu.au Thu Oct 17 08:02:26 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 17 Oct 2002 18:02:26 +1000 (EST) Subject: enter_bug page In-Reply-To: <3DAE6108.4040500@mozilla.org> Message-ID: Yeah, I agree. Combining the two is on my List. You know, the really long one with mod_perl towards the top, below 'finish my honors thesis before the due date'. IMO, combining should be done in parallel with using Bug.pm to do writes. Snce its going to have to be rewritten anyway, I'd prefer to do so only once. Bradley From jeff.hedlund at matrixsi.com Thu Oct 17 12:50:17 2002 From: jeff.hedlund at matrixsi.com (Jeff Hedlund) Date: Thu, 17 Oct 2002 08:50:17 -0400 Subject: enter_bug page References: <3DAE6108.4040500@mozilla.org> Message-ID: <3DAEB209.30306@matrixsi.com> Gervase Markham wrote: > It used to be the case that after you filed a bug, you had to click the > link and wait for it to load before making any further changes. Now, the > bug itself is output after the "bug added" message, so complaints in old > bugs like "It is a multiple step process instead of one" no longer > really apply. It still is a multiple step process, though. I feel like anything that an advanced user would immediately (and often) change upon entering the bug should be [allowable] on the enter_bug page. It reduces bug mail and makes the entering of the bug a much simpler process. > http://bugzilla.mozilla.org/show_bug.cgi?id=112373 has just been checked > in, adding dependencies to the enter_bug page - this has resulted in a > 400-line, 16k patch! And bug 112373 is the only bug I have ever seen > requesting this feature - I actually patched 112373 in order to patch http://bugzilla.mozilla.org/show_bug.cgi?id=141175. So there are at least two bugs for this feature (well, at least one requiring it). > I think we should declare a moratorium on further complication of the > enter_bug page (given the ease with which fields can be changed > immediately after filing), and give serious consideration to backing out > the dependencies patch. I'm good with the moratorium, until we combine the process_bug and post_bug and create an interface to allow arbitrary fields to the front page. (BTW- Here is a meta bug tracking fields to be added to the enter bug page: http://bugzilla.mozilla.org/show_bug.cgi?id=165025) I'd like to keep the 112373 patch in, so that 141175 can be patched. I think keeping 112373 in will help the process_bug/post_bug combination patch, since it adds some features that have never been on post_bug before like logging activity of another bug. Letting my voice be heard :) Jeff -- /\ /\ .. .. .. jeff.hedlund at matrixsi.com / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com From horiuchi at pb.jp.nec.com Thu Oct 17 12:55:05 2002 From: horiuchi at pb.jp.nec.com (HORIUCHI Takahiko) Date: Thu, 17 Oct 2002 21:55:05 +0900 (JST) Subject: Japanese and Chinese characters in same DB Message-ID: <20021017.215505.40720243.horiuchi@pb.jp.nec.com> I'm using bugzilla in a proprietary development between China and Japan. I intend to use Japanese characters and Chinese characters in their own encodings, respectively. After brief test, it seems to work fine, except some rare cases (these rare cases aren't important for us). The situation is - We won't mix different encodings in a bug at the same time. - Summary character encoding will be Japanese or English. - We use double byte characters only in the comments field. - We don't mind character corruption (garbage) in mail subject. So, I want ask you bugzilla experts. Is it dangerous to mix different encodings in same MySQL database, or will it work fine in some degree? We can bear some difficulties at web browser presentation. We will be happy only if we don't lost valuable bug data. There's a Japanese localized version of bugzilla. But I want to use English version if there's not so serious problems. Because for Chinese member, it's easy to understand English than Japanese. I know this is not a question for developers. Sorry... ~~~~ HORIUCHI Takahiko // NEC Informatec Systems [horiuchi at pb.jp.nec.com] // 2nd. Business Solutions / 1st IT division // 03-5232-6527 (8-216-564) From gerv at mozilla.org Thu Oct 17 13:25:49 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Oct 2002 14:25:49 +0100 Subject: enter_bug page References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> Message-ID: <3DAEBA5D.3000107@mozilla.org> Jeff Hedlund wrote: > > Gervase Markham wrote: > >> It used to be the case that after you filed a bug, you had to click >> the link and wait for it to load before making any further changes. >> Now, the bug itself is output after the "bug added" message, so >> complaints in old bugs like "It is a multiple step process instead of >> one" no longer really apply. > > It still is a multiple step process, though. Any sufficiently-complicated change is going to be a multiple-step process, within the limits of an HTML GUI which isn't ridiculously crowded. For example, adding an attachment requires going to a separate screen. We should be aiming to have the most-used features accessible easily, and lesser-used features can require more clicks. > I feel like anything that > an advanced user would immediately (and often) change upon entering the > bug should be [allowable] on the enter_bug page. It reduces bug mail > and makes the entering of the bug a much simpler process. It would have a negligible effect on volumes of bug mail (not much of my bug mail is from NEW bugs, at any rate), and if these users are "advanced", then they should be able to cope with "Here, I've filed my bug. Now, I want to change the dependencies, add a couple more CCs, ACCEPT it and set the priority." > I actually patched 112373 in order to patch > http://bugzilla.mozilla.org/show_bug.cgi?id=141175. So there are at > least two bugs for this feature (well, at least one requiring it). But 141175: "Possibility to press a button on a bug thereby creating a new "sub-bug" that blocks the first bug." I'm afraid that I think this is another terrible idea :-| This again goes against the rule of making the common things easily accessible and letting the less common things take more clicks. This is an action which I doubt I'd use more than once a month - it certainly doesn't justify having UI to reduce it from: "Click "Enter Bug", fill in fields, click "Commit", edit dependencies, click "Commit" to "Click "Enter Bug Which Blocks This Bug", fill in fields, click "Commit". Given that the filling in the fields is the time-consuming issue here, you have saved very little time and yet complicated the show_bug screen, which is already too complex. This bug could be fixed for installations that want it, when process_bug and post_bug are combined, using a simple HTML link, without any additional code. I don't think that it should ever be fixed in core Bugzilla, and certainly doesn't justify the 112373 patch. > I'd like to keep the 112373 patch in, so that 141175 can be patched. I I'd like to back 112373 out, and mark 141175 as WONTFIX :-) Gerv From justdave at syndicomm.com Thu Oct 17 13:40:56 2002 From: justdave at syndicomm.com (David Miller) Date: Thu, 17 Oct 2002 09:40:56 -0400 Subject: enter_bug page In-Reply-To: <3DAEBA5D.3000107@mozilla.org> References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> Message-ID: On 10/17/02 2:25 PM +0100, Gervase Markham wrote: > We should be aiming to have the most-used features accessible > easily, and lesser-used features can require more clicks. Which is exactly the reason I completely disagree with Gerv, both for attachments and dependencies, because those are both VERY frequently used. I get at least new bug notification every two or three days where someone files a bug and immediately attaches a patch to it. That's two bugmails when I could have just gotten one. We frequently have a need for metabugs (though it's probably overused, it's a fact of life) and dependencies on the enter_bug page makes that a lot easier, too. > This bug could be fixed for installations that want it, when process_bug > and post_bug are combined, using a simple HTML link, without any > additional code. I don't think that it should ever be fixed in core > Bugzilla, and certainly doesn't justify the 112373 patch. > >> I'd like to keep the 112373 patch in, so that 141175 can be patched. I > > I'd like to back 112373 out, and mark 141175 as WONTFIX :-) I want 112373 to stay in. Although I do think it would have better waited until process/post got combined. 141175 is a dupe of 81642. 81642 now has a corporate sponsor so it'll happen sooner than we think. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From jeff.hedlund at matrixsi.com Thu Oct 17 13:43:51 2002 From: jeff.hedlund at matrixsi.com (Jeff Hedlund) Date: Thu, 17 Oct 2002 09:43:51 -0400 Subject: enter_bug page References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> Message-ID: <3DAEBE97.50601@matrixsi.com> Gervase Markham wrote: >> It still is a multiple step process, though. > Any sufficiently-complicated change is going to be a multiple-step > process, within the limits of an HTML GUI which isn't ridiculously > crowded. For example, adding an attachment requires going to a separate > screen. We should be aiming to have the most-used features accessible > easily, and lesser-used features can require more clicks. Sure, I agree that adding an attachment requires multiple steps and should. But I don't think that adding a dependency is a sufficiently-complicated change that requires a multistep process. Nor is adding keywords. Nor is adding initial CCs. > It would have a negligible effect on volumes of bug mail (not much of my > bug mail is from NEW bugs, at any rate), and if these users are > "advanced", then they should be able to cope with "Here, I've filed my > bug. Now, I want to change the dependencies, add a couple more CCs, > ACCEPT it and set the priority." True, bug mail reduction is not my motivation. I was just listing it as an added bonus :) > But 141175: "Possibility to press a button on a bug thereby creating a > new "sub-bug" that blocks the first bug." > > I'm afraid that I think this is another terrible idea :-| This again > goes against the rule of making the common things easily accessible and > letting the less common things take more clicks. This is an action which > I doubt I'd use more than once a month - it certainly doesn't justify > having UI to reduce it from: > "Click "Enter Bug", fill in fields, click "Commit", edit dependencies, > click "Commit" > to > "Click "Enter Bug Which Blocks This Bug", fill in fields, click "Commit". I would use this much more often than once a month, probably daily. It does justify the time saved for me. The current UI is: Click Enter Bug->Click Product->Fill in fields->Click Commit->Edit Deps->Commit (I only repeat the UI b/c you missed choosing the product) The suggested 141175 UI would be: Click 'Enter blocking bug'->Change pre-filled fields as necessary, fill in fields->Click Commit With the current UI, you may have forgotten what bug you need to block by the time you get to the edit screen! Well, maybe not, but the suggested UI would make my life much easier. > I'd like to back 112373 out, and mark 141175 as WONTFIX :-) I disagree :) But whatever is best for the entire Bugzilla community, if I'm only one of a few requesting the feature, then I can just patch my bugzilla installation. Jeff -- /\ /\ .. .. .. jeff.hedlund at matrixsi.com / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com From jeff.hedlund at matrixsi.com Thu Oct 17 13:58:20 2002 From: jeff.hedlund at matrixsi.com (Jeff Hedlund) Date: Thu, 17 Oct 2002 09:58:20 -0400 Subject: enter_bug page References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> Message-ID: <3DAEC1FC.60601@matrixsi.com> David Miller wrote: > I want 112373 to stay in. Although I do think it would have better waited > until process/post got combined. Ok, I added a bug for process/post combination: http://bugzilla.mozilla.org/show_bug.cgi?id=174988 Jeff -- /\ /\ .. .. .. jeff.hedlund at matrixsi.com / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com From bbaetz at student.usyd.edu.au Thu Oct 17 14:00:21 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Fri, 18 Oct 2002 00:00:21 +1000 (EST) Subject: enter_bug page In-Reply-To: Message-ID: On Thu, 17 Oct 2002, David Miller wrote: > On 10/17/02 2:25 PM +0100, Gervase Markham wrote: > > > We should be aiming to have the most-used features accessible > > easily, and lesser-used features can require more clicks. > > Which is exactly the reason I completely disagree with Gerv, both for > attachments and dependencies, because those are both VERY frequently used. > I get at least new bug notification every two or three days where someone > files a bug and immediately attaches a patch to it. That's two bugmails > when I could have just gotten one. We frequently have a need for metabugs > (though it's probably overused, it's a fact of life) and dependencies on > the enter_bug page makes that a lot easier, too. Attachments have a lot of extra issues, though, and would be a massive ammount of work. You'd need to move at least some of attachment.cgi into a .pm to share with post_bug (for validation), plus the UI probably won't look the best, either. A lot of stuff relies on having a bug_id already, although since we wouldn't have to check for obsolete attachments, or canedit perms, that may be avoidable. You'd also have to clean up processmail :) Bradley From gerv at mozilla.org Thu Oct 17 14:17:35 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Oct 2002 15:17:35 +0100 Subject: enter_bug page References: Message-ID: <3DAEC67F.70708@mozilla.org> Bradley Baetz wrote: > On Thu, 17 Oct 2002, David Miller wrote: >>On 10/17/02 2:25 PM +0100, Gervase Markham wrote: >>>We should be aiming to have the most-used features accessible >>>easily, and lesser-used features can require more clicks. >> >>Which is exactly the reason I completely disagree with Gerv, both for >>attachments and dependencies, because those are both VERY frequently used. >>I get at least new bug notification every two or three days where someone >>files a bug and immediately attaches a patch to it. That's two bugmails >>when I could have just gotten one. We frequently have a need for metabugs >>(though it's probably overused, it's a fact of life) and dependencies on >>the enter_bug page makes that a lot easier, too. I agree that there's more of an argument for attachment being on the enter_bug page, but I still don't think that's a good idea - both for UI and technical reasons (see below.) I think there is a philosophical difference here - I see the enter_bug page as a starting point - where you put in the main bug details, and then flesh out things like aliases, dependencies, priority, status etc. in a subsequent change, reusing all the code we have to do that. IMO, an enter_bug UI which looked like the show_bug UI (the logical destination of the "you should be able to add anything you can change" view) would be over-complex and confusing, because the people who enter bugs are more often easily-intimidated novice users of the system. > Attachments have a lot of extra issues, though, and would be a massive > ammount of work. If attachments were just a file upload control, then they could be on the enter_bug page. But they aren't (and Bugzilla is much the better for it - we have an excellent and very functional attachments system.) Regarding bug 81642, I am a fan of that - in fact, there's a comment there from me detailing my vision of how exactly this would work. But I like that because it's a far more powerful and general mechanism for approximately the same level of UI complication. Gerv From gerv at mozilla.org Thu Oct 17 17:07:21 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Oct 2002 18:07:21 +0100 Subject: Japanese and Chinese characters in same DB References: <20021017.215505.40720243.horiuchi@pb.jp.nec.com> Message-ID: <3DAEEE49.9030709@mozilla.org> HORIUCHI Takahiko wrote: > So, I want ask you bugzilla experts. Is it dangerous to mix > different encodings in same MySQL database, or will it work > fine in some degree? It's all just 1s and 0s. It should work fine. You have responsibility for sending the data correctly labelled to the browser :-) > There's a Japanese localized version of bugzilla. But I want > to use English version if there's not so serious problems. > Because for Chinese member, it's easy to understand English > than Japanese. The Japanese localised version is, as far as I know, a few versions behind and doesn't support useful new stuff like templates. > I know this is not a question for developers. Sorry... Indeed. Please ask such questions in the newsgroup: netscape.public.mozilla.webtools . Gerv From gerv at mozilla.org Thu Oct 17 17:16:24 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Oct 2002 18:16:24 +0100 Subject: Groups policy References: <3DAE627D.7060909@mozilla.org> <1034840613.757.17.camel@megagerbil> Message-ID: <3DAEF068.5010803@mozilla.org> MattyT wrote: > On Thu, 2002-10-17 at 16:40, Gervase Markham wrote: >>or is it to create a new group for each thing ("canenterbugs" etc.) >>and ask admins to join their new users to all the groups they'd like >>them to have access to (either automatically using the regexp or by >>hand)? > > Avoiding this is the whole reason why the concepts of role and group > should be separated, and the idea of "system groups" removed. If you > have a group, you can say that group gets multiple roles. That makes sense. Is this part of Joel's "industrial-strength groups" patch, or is there another bug open on this? > The existing system groups will hopefully be made into roles sometime > before 2.18, but that doesn't mean we can't introduce new roles now. > Indeed we did exactly that for insiders I believe. But the mechanism we used for insiders (a param naming the group which has that role) is a bit of a hack, and won't really scale. I'd much rather avoid that solution going forward. Gerv From bugreport at peshkin.net Thu Oct 17 17:20:03 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 17 Oct 2002 10:20:03 -0700 Subject: Groups policy References: <3DAE627D.7060909@mozilla.org> <1034840613.757.17.camel@megagerbil> <3DAEF068.5010803@mozilla.org> Message-ID: <3DAEF143.8000704@peshkin.net> Gervase Markham wrote: > MattyT wrote: > >> On Thu, 2002-10-17 at 16:40, Gervase Markham wrote: >> >>> or is it to create a new group for each thing ("canenterbugs" etc.) >>> and ask admins to join their new users to all the groups they'd like >>> them to have access to (either automatically using the regexp or by >>> hand)? >> >> >> Avoiding this is the whole reason why the concepts of role and group >> should be separated, and the idea of "system groups" removed. If you >> have a group, you can say that group gets multiple roles. > > > That makes sense. Is this part of Joel's "industrial-strength groups" > patch, or is there another bug open on this? > I think the groups system provides a foundation on which such a roles system can be built. One that exists, then all the "which group can do what" mappings should convert. -Joel From gerv at mozilla.org Thu Oct 17 17:25:51 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Oct 2002 18:25:51 +0100 Subject: Granularity Message-ID: <3DAEF29F.8010006@mozilla.org> I seem to be writing a lot of these "we need to think about..." emails at the moment :-) This one's about "granularity" - at what levels should you be able to configure Bugzilla to do different things? Currently, for example, you define voting preferences on a per-product basis, whereas the mail formats are global. We have a number of features coming up, such as custom fields, for which a granularity will also have to be chosen. This mail was prompted by MattyT's comments in http://bugzilla.mozilla.org/show_bug.cgi?id=169822 . He points out that, because the new flag types system is _per_component_, this means that we probably need _two_ intermediate screens when changing products on a bug - one to confirm the component, and another to confirm the flags once the component is chosen. He hasn't said so, but this may also mean we need a single confirmation screen when changing component, too - I'm not sure. Anyway, I think that we should standardise on the Product as the granularity for all granular settings. Benefits: - never a need for a second "changing" screen when changing product. - simplicity in code (single variable to check) and database - consistent story to tell customisers - it makes semantic sense This obviously doesn't preclude e.g. UI customisation template hacks on a per-component, or per-anything basis (so you could hide a custom field in a particular set of components, for example), but IMO the Bugzilla back-end logic should have product granularity. Comments? Gerv From gerv at mozilla.org Thu Oct 17 17:29:43 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Oct 2002 18:29:43 +0100 Subject: Changes to default search options References: <3DAB4AA2.1030600@mozilla.org> <3DAB51BE.7030100@peshkin.net> Message-ID: <3DAEF387.2030707@mozilla.org> Joel Peshkin wrote: > Gervase Markham wrote: > >> >> - Default email searches to "exact match" >> http://bugzilla.mozilla.org/show_bug.cgi?id=173567 >> Exact match searches are far less resource-intensive, and evidence >> from the logs shows that people are typing in full email addresses >> and doing substring searches, which is silly. If we default to exact, >> and they type in a substring and search, they get Zarro, quickly, >> and adjust their parameters. Better that than the other way round. >> > > Perhaps the system should first search for users matching the string and > then do the bug search for userid IN (list). That's quite a good idea; except that I suspect the performance would suck if the list was large. We could do this to eliminate some of the JOINs, though - that might speed things up. Gerv From jones at nceas.ucsb.edu Fri Oct 18 00:23:19 2002 From: jones at nceas.ucsb.edu (Matt Jones) Date: Thu, 17 Oct 2002 16:23:19 -0800 Subject: enter_bug page References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> Message-ID: <3DAF5477.7020706@nceas.ucsb.edu> I completely agree with Dave. Bugzilla is great, but one of the few truly annoying aspects of the system is having to return to a bug to enter additional details that could have been entered on the first form. Our bugzilla users often forget things that are not on the enter_bug page, and having to coax them into doing it is a definite pain. Not to mention getting two bug mails for every one that is needed. For us, by far the most relevant field that isn't currently on the form is the target milestone, as it is mostly used in house by developers documenting their own bugs and tasks. But attachments and dependencies would also be a great addition to enter_bug, regardless of the so-called technical difficulties associated with putting attachments there. And it would even be good if developers could "Accept" a bug when they enter it. For us, and I would think more generally, it is common for people to use bugzilla to document their own work, and so Accept'ing the bug should be automatic in that case. Matt David Miller wrote: > On 10/17/02 2:25 PM +0100, Gervase Markham wrote: > > >>We should be aiming to have the most-used features accessible >>easily, and lesser-used features can require more clicks. > > > Which is exactly the reason I completely disagree with Gerv, both for > attachments and dependencies, because those are both VERY frequently used. > I get at least new bug notification every two or three days where someone > files a bug and immediately attaches a patch to it. That's two bugmails > when I could have just gotten one. We frequently have a need for metabugs > (though it's probably overused, it's a fact of life) and dependencies on > the enter_bug page makes that a lot easier, too. > > >>This bug could be fixed for installations that want it, when process_bug >>and post_bug are combined, using a simple HTML link, without any >>additional code. I don't think that it should ever be fixed in core >>Bugzilla, and certainly doesn't justify the 112373 patch. >> >> >>>I'd like to keep the 112373 patch in, so that 141175 can be patched. I >> >>I'd like to back 112373 out, and mark 141175 as WONTFIX :-) > > > I want 112373 to stay in. Although I do think it would have better waited > until process/post got combined. > > 141175 is a dupe of 81642. 81642 now has a corporate sponsor so it'll > happen sooner than we think. -- ******************************************************************* Matt Jones jones at nceas.ucsb.edu http://www.nceas.ucsb.edu/ National Center for Ecological Analysis and Synthesis (NCEAS) Interested in ecological informatics? http://www.ecoinformatics.org ******************************************************************* From horiuchi at pb.jp.nec.com Fri Oct 18 04:49:10 2002 From: horiuchi at pb.jp.nec.com (HORIUCHI Takahiko) Date: Fri, 18 Oct 2002 13:49:10 +0900 (JST) Subject: Japanese and Chinese characters in same DB In-Reply-To: <3DAEEE49.9030709@mozilla.org> References: <20021017.215505.40720243.horiuchi@pb.jp.nec.com> <3DAEEE49.9030709@mozilla.org> Message-ID: <20021018.134910.103171801.horiuchi@pb.jp.nec.com> > > So, I want ask you bugzilla experts. Is it dangerous to mix > > different encodings in same MySQL database, or will it work > > fine in some degree? > > It's all just 1s and 0s. It should work fine. You have responsibility > for sending the data correctly labelled to the browser :-) I'm happy to hear that. > The Japanese localised version is, as far as I know, a few versions > behind and doesn't support useful new stuff like templates. Yes. Latest version is v2.12, maybe. > > I know this is not a question for developers. Sorry... > > Indeed. Please ask such questions in the newsgroup: > netscape.public.mozilla.webtools . I see. Next time, I'll go the newsgroup. Thank you. ~~~~ HORIUCHI Takahiko // NEC Informatec Systems [horiuchi at pb.jp.nec.com] // 2nd. Business Solutions / 1st IT division // 03-5232-6527 (8-216-564) From gerv at mozilla.org Fri Oct 18 06:59:46 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 18 Oct 2002 07:59:46 +0100 Subject: enter_bug page In-Reply-To: <3DAE6108.4040500@mozilla.org> References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> <3DAF5477.7020706@nceas.ucsb.edu> Message-ID: <3DAFB162.8050701@mozilla.org> Matt Jones wrote: > I completely agree with Dave. Bugzilla is great, but one of the few > truly annoying aspects of the system is having to return to a bug to > enter additional details that could have been entered on the first form. > > For us, by far the most relevant field that isn't currently on the > form is the target milestone, Obviously, this will be different for different people - hence the need to unify post_bug and process_bug to allow sites to customise what they want on the enter_bug page. I think we are all agreed that this is the correct long-term solution. But I assert two things: - prior to that code change, we should not duplicate more and more of process_bug in post_bug by adding more things to the current enter_bug architecture - after that change, the _default_ enter_bug screen should remain the simple thing that it now is, rather than being as complex as show_bug. Gerv From justdave at syndicomm.com Mon Oct 21 04:59:46 2002 From: justdave at syndicomm.com (David Miller) Date: Mon, 21 Oct 2002 00:59:46 -0400 Subject: enter_bug page In-Reply-To: <3DAFB162.8050701@mozilla.org> References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> <3DAF5477.7020706@nceas.ucsb.edu> <3DAFB162.8050701@mozilla.org> Message-ID: On 10/18/02 7:59 AM +0100, Gervase Markham wrote: > - after that change, the _default_ enter_bug screen should remain the > simple thing that it now is, rather than being as complex as show_bug. Or we can have a few different versions depending on who the person is or what product the bug is being filed in. (See http://bugzilla.mozilla.org/show_bug.cgi?id=173127 ) -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From gerv at mozilla.org Mon Oct 21 07:22:01 2002 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 21 Oct 2002 08:22:01 +0100 Subject: enter_bug page In-Reply-To: <3DAE6108.4040500@mozilla.org> References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> <3DAF5477.7020706@nceas.ucsb.edu> <3DAFB162.8050701@mozilla.org> Message-ID: <3DB3AB19.9040305@mozilla.org> David Miller wrote: > >- after that change, the _default_ enter_bug screen should remain the > >simple thing that it now is, rather than being as complex as show_bug. > > Or we can have a few different versions depending on who the person is or > what product the bug is being filed in. > (See http://bugzilla.mozilla.org/show_bug.cgi?id=173127 ) Of course individual Bugzilla installations can have as many custom views as they like - and we should support that (and I still think we should use CSS - see my comments in that bug.) But I don't think the _default_ Bugzilla needs more than two - the current, simple page and a copy of the mozilla.org Bugzilla Helper as a technology demo of what's possible using custom templates and enter_bug comment formats (which are really complex to explain and much easier to demonstrate.) More is just a maintenance headache IMO. Gerv From justdave at syndicomm.com Mon Oct 21 13:51:14 2002 From: justdave at syndicomm.com (David Miller) Date: Mon, 21 Oct 2002 09:51:14 -0400 Subject: enter_bug page In-Reply-To: <3DB3AB19.9040305@mozilla.org> References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> <3DAF5477.7020706@nceas.ucsb.edu> <3DAFB162.8050701@mozilla.org> <3DB3AB19.9040305@mozilla.org> Message-ID: On 10/21/02 8:22 AM +0100, Gervase Markham wrote: > But I don't think the _default_ Bugzilla needs more than two - the > current, simple page and a copy of the mozilla.org Bugzilla Helper as a > technology demo of what's possible using custom templates and enter_bug > comment formats (which are really complex to explain and much easier to > demonstrate.) More is just a maintenance headache IMO. I think we should have three in the default installation. One that's a little bit more stripped down than the existing one, one that lets you enter anything you can change in your new bug report (i.e. a complete bug entry like everyone's asking for), and the Bugzilla Helper. The second one will have to wait till we get process and post merged. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From jeff.hedlund at matrixsi.com Mon Oct 21 16:27:07 2002 From: jeff.hedlund at matrixsi.com (Jeff Hedlund) Date: Mon, 21 Oct 2002 12:27:07 -0400 Subject: Target Date - Bug 103636 Message-ID: <3DB42ADB.1070807@matrixsi.com> Some comments on bug 103636 (http://bugzilla.mozilla.org/show_bug.cgi?id=103636) state that custom fields should take care of this feature. I still disagree due to the more integrated nature of the target_date field, and so I would like to hash it out on the developers mailing list. Reasons I believe it should not be a custom field: Integrated into the importance sort Handling of the "emtpy" date Gut feeling :) The way I handled the empty date is by putting the value 9999-12-31. The reason I am using that is for better sorting (so that bugs with dates will be sorted higher than those without). But in order for that to look right, I filter out any date with 9999 so the user sees an empty date and not this funky 9999-12-31 date. Thoughts? Jeff -- /\ /\ .. .. .. jeff.hedlund at matrixsi.com / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com From gerv at mozilla.org Mon Oct 21 22:33:50 2002 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 21 Oct 2002 23:33:50 +0100 Subject: enter_bug page In-Reply-To: <3DAE6108.4040500@mozilla.org> References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> <3DAF5477.7020706@nceas.ucsb.edu> <3DAFB162.8050701@mozilla.org> <3DB3AB19.9040305@mozilla.org> Message-ID: <3DB480CE.5090602@mozilla.org> > I think we should have three in the default installation. One that's a > little bit more stripped down than the existing one, one that lets you > enter anything you can change in your new bug report (i.e. a complete bug > entry like everyone's asking for), and the Bugzilla Helper. The > second one > will have to wait till we get process and post merged. OK, I'll buy that. Does this view mean we shouldn't be adding more stuff to the current enter_bug page? :-) Gerv From justdave at syndicomm.com Mon Oct 21 22:41:30 2002 From: justdave at syndicomm.com (David Miller) Date: Mon, 21 Oct 2002 18:41:30 -0400 Subject: enter_bug page In-Reply-To: <3DB480CE.5090602@mozilla.org> References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> <3DAF5477.7020706@nceas.ucsb.edu> <3DAFB162.8050701@mozilla.org> <3DB3AB19.9040305@mozilla.org> <3DB480CE.5090602@mozilla.org> Message-ID: On 10/21/02 11:33 PM +0100, Gervase Markham wrote: >> I think we should have three in the default installation. One that's a >> little bit more stripped down than the existing one, one that lets you >> enter anything you can change in your new bug report (i.e. a complete bug >> entry like everyone's asking for), and the Bugzilla Helper. The >> second one >> will have to wait till we get process and post merged. > > OK, I'll buy that. Does this view mean we shouldn't be adding more stuff > to the current enter_bug page? :-) Yes. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From myk at mozilla.org Tue Oct 22 00:28:14 2002 From: myk at mozilla.org (Myk Melez) Date: Mon, 21 Oct 2002 17:28:14 -0700 Subject: enter_bug page In-Reply-To: <3DAE6108.4040500@mozilla.org> References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> <3DAF5477.7020706@nceas.ucsb.edu> <3DAFB162.8050701@mozilla.org> <3DB3AB19.9040305@mozilla.org> Message-ID: <3DB49B9E.3040907@mozilla.org> David Miller wrote: >On 10/21/02 8:22 AM +0100, Gervase Markham wrote: > > > >>But I don't think the _default_ Bugzilla needs more than two - the >>current, simple page and a copy of the mozilla.org Bugzilla Helper as a >>technology demo of what's possible using custom templates and enter_bug >>comment formats (which are really complex to explain and much easier to >>demonstrate.) More is just a maintenance headache IMO. >> >> > >I think we should have three in the default installation. One that's a >little bit more stripped down than the existing one, one that lets you >enter anything you can change in your new bug report (i.e. a complete bug >entry like everyone's asking for), and the Bugzilla Helper. The second one >will have to wait till we get process and post merged. > I think Gerv and you are both partially right on this issue, but this doesn't really satisfy either of your requirements. Advanced users want more options on the page, but that doesn't mean all options will make them more productive. I'd like to see the Bugzilla Helper take over the low end and a smarter form (with the most frequently requested fields) deal with the rest. This could include removing (or automatically setting) fields from the current form that aren't frequently used. -myk From myk at mozilla.org Tue Oct 22 00:56:11 2002 From: myk at mozilla.org (Myk Melez) Date: Mon, 21 Oct 2002 17:56:11 -0700 Subject: Japanese and Chinese characters in same DB In-Reply-To: <20021017.215505.40720243.horiuchi@pb.jp.nec.com> References: <20021017.215505.40720243.horiuchi@pb.jp.nec.com> Message-ID: <3DB4A22B.4010405@mozilla.org> HORIUCHI Takahiko wrote: >So, I want ask you bugzilla experts. Is it dangerous to mix >different encodings in same MySQL database, or will it work >fine in some degree? > There's some evidence that it works and some issues with Bugzilla that may need to be resolved for it to work better (in particular bug 126266). One suggestion I have heard is that if you are starting with a new Bugzilla installation and are willing to enter everything in Unicode you can set the default charset for all Bugzilla pages accordingly and not have any problems at all. http://bugzilla.mozilla.org/show_bug.cgi?id=126266 -myk From myk at mozilla.org Tue Oct 22 01:13:29 2002 From: myk at mozilla.org (Myk Melez) Date: Mon, 21 Oct 2002 18:13:29 -0700 Subject: Granularity In-Reply-To: <3DAEF29F.8010006@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> Message-ID: <3DB4A639.4050609@mozilla.org> Gervase Markham wrote: > Anyway, I think that we should standardise on the Product as the > granularity for all granular settings. Benefits: > > - never a need for a second "changing" screen when changing product. > - simplicity in code (single variable to check) and database > - consistent story to tell customisers > - it makes semantic sense These are all valid considerations, but most of them are about how we would like to perceive Bugzilla rather than how it could be most useful to us. I too would like Bugzilla to be simple, consistent, and semantically sensible, but I'd rather have it be messy, inconsistent, and doing the things I need it to do. Bugzilla's feature set grows primarily through the needs of its installations, and there's already been at least one demonstrated need for component-level specificity, not to mention lots of examples where even product-level specificity is not needed or is of such low priority that no one does it despite us all having talked about it for years. We might (and do, I think, through discussions and the "make everything product-specific" bug 106592) promulgate this approach as a general principle, but we shouldn't block our developers and installations from deviating from it when necessary and useful. -myk From justdave at syndicomm.com Tue Oct 22 02:05:12 2002 From: justdave at syndicomm.com (David Miller) Date: Mon, 21 Oct 2002 22:05:12 -0400 Subject: Granularity In-Reply-To: <3DB4A639.4050609@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> <3DB4A639.4050609@mozilla.org> Message-ID: On 10/21/02 6:13 PM -0700, Myk Melez wrote: > Bugzilla's feature set grows primarily through the needs of its > installations, and there's already been at least one demonstrated need > for component-level specificity, not to mention lots of examples where > even product-level specificity is not needed or is of such low priority > that no one does it despite us all having talked about it for years. > > We might (and do, I think, through discussions and the "make everything > product-specific" bug 106592) promulgate this approach as a general > principle, but we shouldn't block our developers and installations from > deviating from it when necessary and useful. There was a bug somewhere (I forget the number) about merging products and components and making components have children. Everything would be at the component level (because that's all there is) but children would inherit, unless the child overrides it. This would let you set it at whatever granularity you wanted. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From bbaetz at student.usyd.edu.au Tue Oct 22 02:28:25 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Tue, 22 Oct 2002 12:28:25 +1000 (EST) Subject: Granularity In-Reply-To: Message-ID: On Mon, 21 Oct 2002, David Miller wrote: > There was a bug somewhere (I forget the number) about merging products and > components and making components have children. Everything would be at the > component level (because that's all there is) but children would inherit, > unless the child overrides it. This would let you set it at whatever > granularity you wanted. :) > Yeah, thats nice in theory, and makes some DB stuff nicer, but in practice the UI for infinite levels is likely to be a massive pain, unfortunately. Bradley From justdave at syndicomm.com Tue Oct 22 03:16:11 2002 From: justdave at syndicomm.com (David Miller) Date: Mon, 21 Oct 2002 23:16:11 -0400 Subject: Granularity In-Reply-To: References: Message-ID: On 10/22/02 12:28 PM +1000, Bradley Baetz wrote: > On Mon, 21 Oct 2002, David Miller wrote: > >> There was a bug somewhere (I forget the number) about merging products and >> components and making components have children. Everything would be at the >> component level (because that's all there is) but children would inherit, >> unless the child overrides it. This would let you set it at whatever >> granularity you wanted. :) >> > > Yeah, thats nice in theory, and makes some DB stuff nicer, but in practice > the UI for infinite levels is likely to be a massive pain, unfortunately. There was one suggestion to go two or three levels in on separate controls, then flatten everything from that point with a colon between them. Like the Browser product on b.m.o is already doing with DOM and XP Apps and so forth. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From gerv at mozilla.org Tue Oct 22 06:32:17 2002 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 22 Oct 2002 07:32:17 +0100 Subject: Granularity In-Reply-To: References: Message-ID: <3DB4F0F1.7080703@mozilla.org> > There was one suggestion to go two or three levels in on separate > controls, > then flatten everything from that point with a colon between them. Like > the Browser product on b.m.o is already doing with DOM and XP Apps and so > forth. Then how is it an improvement over the current system, where people just, er, use a colon? :-) Also, it's not just the user UI - the admin UI would be really complex. Gerv From gerv at mozilla.org Tue Oct 22 06:40:34 2002 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 22 Oct 2002 07:40:34 +0100 Subject: enter_bug page In-Reply-To: <3DAE6108.4040500@mozilla.org> References: <3DAE6108.4040500@mozilla.org> <3DAEB209.30306@matrixsi.com> <3DAEBA5D.3000107@mozilla.org> <3DAF5477.7020706@nceas.ucsb.edu> <3DAFB162.8050701@mozilla.org> <3DB3AB19.9040305@mozilla.org> <3DB49B9E.3040907@mozilla.org> Message-ID: <3DB4F2E2.1030203@mozilla.org> Myk Melez wrote: > I think Gerv and you are both partially right on this issue, but this > doesn't really satisfy either of your requirements. Advanced users want > more options on the page, but that doesn't mean all options will make > them more productive. > > I'd like to see the Bugzilla Helper take over the low end and a smarter > form (with the most frequently requested fields) deal with the rest. > This could include removing (or automatically setting) fields from the > current form that aren't frequently used. IMO, the Bugzilla Helper is unsuitable for anything other than a technology demo, because it is intentionally very Mozilla specific. I wouldn't want to change that, because one of the advantages of checking it in is that we can maintain the Mozilla version in Bugzilla CVS. "Low-end" doesn't mean clueless end-users, it means people who hold the "bug entry is a starting point" view I outlined earlier in the thread. Gerv From mbarnson at sisna.com Wed Oct 23 04:16:25 2002 From: mbarnson at sisna.com (Matthew P. Barnson) Date: 22 Oct 2002 22:16:25 -0600 Subject: Bugzilla as CMF product? Message-ID: <1035346585.3371.12.camel@chandler.int.barnson.org> I've been playing the Zope Content Management Framework world for the last couple of weeks, building a documentation database and integrated paperless workflow stuff for my company. Unfortunately, the "Collector" product for CMF, as it stands for bug-tracking, is kind of a running joke. Considering that, last I recall, Mozilla.org was planned to move to a Zope/CMF-based infrastructure at some point in the future (documentation, web site, etc., plans could have changed since I've been out of the loop so long), has anybody considered creating a Zope port of Bugzilla? Zope can run Perl and Python code natively as products, though they need to be "Zopeified" to work right. If I get no response, I'll simply assume nobody has done work in that area before, and I'll see what I can crank out. The idea of an integrated workflow management tool, and a bug-tracking system that respects that workflow and inherited user rights with a database-agnostic back-end, is very appealing... --Matt Barnson From louie at ximian.com Wed Oct 23 04:17:05 2002 From: louie at ximian.com (Luis Villa) Date: 23 Oct 2002 00:17:05 -0400 Subject: Bugzilla as CMF product? In-Reply-To: <1035346585.3371.12.camel@chandler.int.barnson.org> References: <1035346585.3371.12.camel@chandler.int.barnson.org> Message-ID: <1035346624.9257.68.camel@localhost.localdomain> FWIW, the zope installation we had at www.gnome.org was a huge problem, constantly going nuts, swamping CPU, memory, and/or the DB. We finally just nuked it. That may have been more of a flaw of the app running on zope than the platform itself, though. Luis On Wed, 2002-10-23 at 00:16, Matthew P. Barnson wrote: > I've been playing the Zope Content Management Framework world for the > last couple of weeks, building a documentation database and integrated > paperless workflow stuff for my company. Unfortunately, the "Collector" > product for CMF, as it stands for bug-tracking, is kind of a running > joke. > > Considering that, last I recall, Mozilla.org was planned to move to a > Zope/CMF-based infrastructure at some point in the future > (documentation, web site, etc., plans could have changed since I've been > out of the loop so long), has anybody considered creating a Zope port of > Bugzilla? Zope can run Perl and Python code natively as products, > though they need to be "Zopeified" to work right. If I get no response, > I'll simply assume nobody has done work in that area before, and I'll > see what I can crank out. The idea of an integrated workflow management > tool, and a bug-tracking system that respects that workflow and > inherited user rights with a database-agnostic back-end, is very > appealing... > > --Matt Barnson > > > > ---- > To view or change your list settings, click here: > > From matthew at barnson.org Wed Oct 23 04:11:41 2002 From: matthew at barnson.org (Matthew P. Barnson) Date: 22 Oct 2002 22:11:41 -0600 Subject: Granularity In-Reply-To: <3DB4F0F1.7080703@mozilla.org> References: <3DB4F0F1.7080703@mozilla.org> Message-ID: <1035346301.3376.6.camel@chandler.int.barnson.org> I've played this game in Scarab, and the idea of infinite nested levels, as mentioned, is simply a royal pain in the butt. Component-level permissions granularity would be a wonderful thing, but to make them infinitely "nestable" is generally A Bad Thing. I've been monkeying around with Scarab (cool, but nowhere near "complete" yet) and Zope Collectors (working, but very very rudimentary) over the last few weeks. To make folders have a less "static" behavior would definitely be more than a trivial reworking. On Tue, 2002-10-22 at 00:32, Gervase Markham wrote: > Also, it's not just the user UI - the admin UI would be really complex. -- Matthew P. Barnson Sr. UNIX Systems Administrator DAM Computer Consulting, Inc. "When you cuss, think of us!" "...the general idea that [the Supreme Court ]will restrain itself, despite believing a law is stupid, is a feature, not a bug in our constitutional tradition." -Lawrence Lessig nd 100%". --Penn Jillette one and drive on without guilt! -ccm From kiko at async.com.br Wed Oct 23 13:23:30 2002 From: kiko at async.com.br (Christian Reis) Date: Wed, 23 Oct 2002 10:23:30 -0300 Subject: Bugzilla as CMF product? In-Reply-To: <1035346624.9257.68.camel@localhost.localdomain>; from louie@ximian.com on Wed, Oct 23, 2002 at 12:17:05AM -0400 References: <1035346585.3371.12.camel@chandler.int.barnson.org> <1035346624.9257.68.camel@localhost.localdomain> Message-ID: <20021023102330.F6326@blackjesus.async.com.br> On Wed, Oct 23, 2002 at 12:17:05AM -0400, Luis Villa wrote: > FWIW, the zope installation we had at www.gnome.org was a huge problem, > constantly going nuts, swamping CPU, memory, and/or the DB. We finally > just nuked it. That may have been more of a flaw of the app running on > zope than the platform itself, though. Just to add a counterpoint, we've used Zope and installed it in many sites with great performance and very nice flexibility to end-users that want to administer their sites. The latest versions have improved a lot towards stability and footprint (haven't we all :-) so it may be that GNOME's installation might have been an old crufty version. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From louie at ximian.com Wed Oct 23 13:34:06 2002 From: louie at ximian.com (Luis Villa) Date: 23 Oct 2002 09:34:06 -0400 Subject: Bugzilla as CMF product? In-Reply-To: <20021023102330.F6326@blackjesus.async.com.br> References: <1035346585.3371.12.camel@chandler.int.barnson.org> <1035346624.9257.68.camel@localhost.localdomain> <20021023102330.F6326@blackjesus.async.com.br> Message-ID: <1035380045.9257.75.camel@localhost.localdomain> On Wed, 2002-10-23 at 09:23, Christian Reis wrote: > On Wed, Oct 23, 2002 at 12:17:05AM -0400, Luis Villa wrote: > > FWIW, the zope installation we had at www.gnome.org was a huge problem, > > constantly going nuts, swamping CPU, memory, and/or the DB. We finally > > just nuked it. That may have been more of a flaw of the app running on > > zope than the platform itself, though. > > Just to add a counterpoint, we've used Zope and installed it in many > sites with great performance and very nice flexibility to end-users that > want to administer their sites. The latest versions have improved a lot > towards stability and footprint (haven't we all :-) so it may be that > GNOME's installation might have been an old crufty version. Old and crufty version at GNOME? say it ain't so! :) Luis (putting off the 2.16 upgrade, still :/ From kiko at async.com.br Wed Oct 23 14:26:20 2002 From: kiko at async.com.br (Christian Reis) Date: Wed, 23 Oct 2002 11:26:20 -0300 Subject: Bugzilla as CMF product? In-Reply-To: <1035346585.3371.12.camel@chandler.int.barnson.org>; from mbarnson@sisna.com on Tue, Oct 22, 2002 at 10:16:25PM -0600 References: <1035346585.3371.12.camel@chandler.int.barnson.org> Message-ID: <20021023112620.R6326@blackjesus.async.com.br> On Tue, Oct 22, 2002 at 10:16:25PM -0600, Matthew P. Barnson wrote: > I've been playing the Zope Content Management Framework world for the > last couple of weeks, building a documentation database and integrated > paperless workflow stuff for my company. Unfortunately, the "Collector" > product for CMF, as it stands for bug-tracking, is kind of a running > joke. Yep, even Python uses the (gasp) sf.net bugtracker. > Considering that, last I recall, Mozilla.org was planned to move to a > Zope/CMF-based infrastructure at some point in the future > (documentation, web site, etc., plans could have changed since I've been > out of the loop so long), has anybody considered creating a Zope port of It's been going sloooow. There is a test site up on mozdev, and Gerv is involved with it, but so far not a lot of progress has been done. As far as I can see it (and I'm not too informed) there seems to have been a lot of focus on "skinning", when the real problems (site organization, content management, etc) have been sort of sidetracked. Am I mistaken, Gerv? > Bugzilla? Zope can run Perl and Python code natively as products, > though they need to be "Zopeified" to work right. If I get no response, > I'll simply assume nobody has done work in that area before, and I'll > see what I can crank out. The idea of an integrated workflow management > tool, and a bug-tracking system that respects that workflow and > inherited user rights with a database-agnostic back-end, is very > appealing... Nope, nothing has been done in this area before. Me and Johan here at the office often toy with the idea of porting Bugzilla to Python and making it easier to code for us, but we are never very serious about it :) Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From mbarnson at sisna.com Wed Oct 23 16:22:56 2002 From: mbarnson at sisna.com (Matthew P. Barnson) Date: 23 Oct 2002 10:22:56 -0600 Subject: Bugzilla as CMF product? In-Reply-To: <20021023112620.R6326@blackjesus.async.com.br> References: <1035346585.3371.12.camel@chandler.int.barnson.org> <20021023112620.R6326@blackjesus.async.com.br> Message-ID: <1035390177.15890.9.camel@chandler.int.barnson.org> On Wed, 2002-10-23 at 08:26, Christian Reis wrote: > Nope, nothing has been done in this area before. Me and Johan here at > the office often toy with the idea of porting Bugzilla to Python and > making it easier to code for us, but we are never very serious about it I'm finding that I need good bug-tracking, but that I'd prefer it work under Zope/CMF. My personal feel after reviewing Bugzilla again this morning (I've spent the last year that I haven't worked on Bugzilla docs working on various personal programming and admin things) is that any "port" to Zope-CMF/Python would be a look-and-feel "port" only. Under the hood, the whole framework is so different as to boggle the mind. The only things that I think could be lifted wholesale and ported to Python would be perhaps aspects of the email handling, page formatting, and (perhaps) search algorithms. Even those, though, could largely be abstracted out into stock Zope modules. A Bugzilla port to Zope/CMF would not be Bugzilla at all... If anybody's interested in helping out, just let me know :) In the meantime, I'll see what I can come up with. DTML is pretty much right out, but DCWorkflow seems like it could handle workflow/state changes for BZ pretty well, and at the heart of it, Bugzilla is just a state machine. "Just". Heh, Heh. I'm trying to figure out what to call it, though I hate it when I'm long on talk and short on code. Ideas welcome... "CMFBugzilla" seems a logical name, but some folks might object... --Matt Barnson From gerv at mozilla.org Wed Oct 23 17:30:45 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 Oct 2002 18:30:45 +0100 Subject: Bugzilla as CMF product? In-Reply-To: <1035346585.3371.12.camel@chandler.int.barnson.org> References: <1035346585.3371.12.camel@chandler.int.barnson.org> Message-ID: <3DB6DCC5.8040806@mozilla.org> > Considering that, last I recall, Mozilla.org was planned to move to a > Zope/CMF-based infrastructure at some point in the future If this ever happens, it'll be a long way off. It foundered on objections among staff, and the people working on it haven't come back with another proposal. I'm not really involved any more. > out of the loop so long), has anybody considered creating a Zope port of > Bugzilla? Why would you want to do that? A lot of work for not much gain, as I see it. > see what I can crank out. The idea of an integrated workflow management > tool, and a bug-tracking system that respects that workflow and > inherited user rights with a database-agnostic back-end, is very > appealing... If you want to share user rights, use LDAP. Why do you need a database-agnostic back end? Just use the right tool for the job - in Bugzilla's case, MySQL. If your workflow is so complex that there needs to be automatic syncing between Zope and Bugzilla (rather than manually updating each with changes), then consider simplifying your workflow :-) Gerv From gerv at mozilla.org Wed Oct 23 17:30:36 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 Oct 2002 18:30:36 +0100 Subject: Bugzilla as CMF product? In-Reply-To: <1035346585.3371.12.camel@chandler.int.barnson.org> References: <1035346585.3371.12.camel@chandler.int.barnson.org> <20021023112620.R6326@blackjesus.async.com.br> Message-ID: <3DB6DCBC.2040209@mozilla.org> > Nope, nothing has been done in this area before. Me and Johan here at > the office often toy with the idea of porting Bugzilla to Python and > making it easier to code for us, but we are never very serious about it > :) If you port it to Python, you may well be working on it on your own :-) Gerv From gerv at mozilla.org Wed Oct 23 17:40:01 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 Oct 2002 18:40:01 +0100 Subject: Target Date - Bug 103636 In-Reply-To: <3DB42ADB.1070807@matrixsi.com> References: <3DB42ADB.1070807@matrixsi.com> Message-ID: <3DB6DEF1.4080408@mozilla.org> Jeff Hedlund wrote: > Reasons I believe it should not be a custom field: > > Integrated into the importance sort > Handling of the "emtpy" date > Gut feeling :) > > The way I handled the empty date is by putting the value 9999-12-31. The > reason I am using that is for better sorting (so that bugs with dates > will be sorted higher than those without). But in order for that to > look right, I filter out any date with 9999 so the user sees an empty > date and not this funky 9999-12-31 date. Custom fields should be able to define how to sort them, so that won't be an issue. And yes, we should enable admins to define the different types of sort you can have on a bug. But both of the above are extra candy, and could be implemented as local changes anyway (neither is large) even if we don't have a customisation mechanism. Adding more hard-coded fields to Bugzilla takes us precisely in the opposite direction to the one we want to go in. Gerv From gerv at mozilla.org Wed Oct 23 17:47:21 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 Oct 2002 18:47:21 +0100 Subject: Granularity In-Reply-To: <3DAEF29F.8010006@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> <3DB4A639.4050609@mozilla.org> Message-ID: <3DB6E0A9.9000806@mozilla.org> Myk Melez wrote: > Bugzilla's feature set grows primarily through the needs of its > installations, and there's already been at least one demonstrated need > for component-level specificity, Are you talking about flag types here? Where is the demonstrated need for component-level specificity? This particular specificity is causing problems (see the bug I cited earlier.) > not to mention lots of examples where > even product-level specificity is not needed or is of such low priority > that no one does it despite us all having talked about it for years. Indeed. My proposal was not to eliminate global parameters :-) It was more to suggest that we make "per-product" and "global" the only two valid values for a specificity. Gerv From gerv at mozilla.org Wed Oct 23 22:44:13 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 Oct 2002 23:44:13 +0100 Subject: Performance measurements Message-ID: <3DB7263D.9060401@mozilla.org> Can people please share with the list the tools they use to measure Bugzilla performance? For example, does MySQL have a way to time a query? How do you time the execution of a CGI script in a webserver? What's the Perl profiler called, if there is one, and where can I find out about it? That sort of stuff... :-) Gerv From bbaetz at student.usyd.edu.au Wed Oct 23 23:08:58 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 24 Oct 2002 09:08:58 +1000 (EST) Subject: Performance measurements In-Reply-To: <3DB7263D.9060401@mozilla.org> Message-ID: On Wed, 23 Oct 2002, Gervase Markham wrote: > Can people please share with the list the tools they use to measure > Bugzilla performance? For example, does MySQL have a way to time a > query? When you run teh query from mysql it shows the time taken at the end :) I have a script to generate n bugs; I'll tidy it up and attach it this evening. > How do you time the execution of a CGI script in a webserver? The best way is to time it from teh cmd line, redirecting to /dev/null, so: time REQUEST_METHOD=GET QUERY_STRING="foo=bar&bar=1" perl -wT foo.cgi > /dev/null > What's the Perl profiler called, if there is one, and where can I find > out about it? perldoc DProf. dprofpp -S is often useful Note that occasionally running with -d:DProf segfaults on me; running it again fixes it. Thats a perl bug which I haven't managed to track down/report/etc. > That sort of stuff... :-) > > Gerv Bradley From tara at tequilarista.org Wed Oct 23 23:34:57 2002 From: tara at tequilarista.org (Tara Hernandez) Date: Wed, 23 Oct 2002 16:34:57 -0700 Subject: Performance measurements References: Message-ID: <3DB73221.4090302@tequilarista.org> Note that there's the standard problem with performance testing which is the act of measuring can affect the results. If you want to do some really good benchmarking, measure from a different machine on the same subnet (to reduce network lag issues). My $0.02 -Tara Bradley Baetz wrote: >On Wed, 23 Oct 2002, Gervase Markham wrote: > > > >>Can people please share with the list the tools they use to measure >>Bugzilla performance? For example, does MySQL have a way to time a >>query? >> >> > >When you run teh query from mysql it shows the time taken at the end :) > >I have a script to generate n bugs; I'll tidy it up and attach it this >evening. > > > >>How do you time the execution of a CGI script in a webserver? >> >> > >The best way is to time it from teh cmd line, redirecting to /dev/null, >so: > >time REQUEST_METHOD=GET QUERY_STRING="foo=bar&bar=1" perl -wT foo.cgi > /dev/null > > > >>What's the Perl profiler called, if there is one, and where can I find >>out about it? >> >> > >perldoc DProf. > >dprofpp -S is often useful > >Note that occasionally running with -d:DProf segfaults on me; running it >again fixes it. Thats a perl bug which I haven't managed to track >down/report/etc. > > > >>That sort of stuff... :-) >> >>Gerv >> >> > >Bradley > >---- >To view or change your list settings, click here: > > > > > From bugreport at peshkin.net Wed Oct 23 23:47:58 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 23 Oct 2002 16:47:58 -0700 Subject: Performance measurements References: <3DB7263D.9060401@mozilla.org> Message-ID: <3DB7352E.9050605@peshkin.net> Gervase Markham wrote: > Can people please share with the list the tools they use to measure > Bugzilla performance? For example, does MySQL have a way to time a > query? How do you time the execution of a CGI script in a webserver? > What's the Perl profiler called, if there is one, and where can I find > out about it? That sort of stuff... :-) > > Gerv > OK -- time for me to confess.... I usually hack a chunk of code into sanitycheck.cgi that checks the time, runs the query *many* times, then prints the time elapsed. As long as I am checking one version of something agains another, it is not a bad way to test. I rarely care about a 5% or 10% differrence, though. Uusually, it is order-of-magnitude. Perhaps we should add a mode to SendSQL that permits us to repeat non-destructive queries enough to get a reasonable average? -Joel From bbaetz at student.usyd.edu.au Thu Oct 24 00:00:02 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 24 Oct 2002 10:00:02 +1000 (EST) Subject: Performance measurements In-Reply-To: <3DB7352E.9050605@peshkin.net> Message-ID: On Wed, 23 Oct 2002, Joel Peshkin wrote: > Perhaps we should add a mode to SendSQL that permits us to repeat > non-destructive queries enough to get a reasonable average? If you're interested in one particular query, you're better off using mysql's command line stuff, and playing with EXPLAIN. > > -Joel > Bradley From myk at mozilla.org Thu Oct 24 00:29:36 2002 From: myk at mozilla.org (Myk Melez) Date: Wed, 23 Oct 2002 17:29:36 -0700 Subject: Granularity In-Reply-To: <3DAEF29F.8010006@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> <3DB4A639.4050609@mozilla.org> <3DB6E0A9.9000806@mozilla.org> Message-ID: <3DB73EF0.6080106@mozilla.org> Gervase Markham wrote: > Are you talking about flag types here? Where is the demonstrated need > for component-level specificity? There are (at least) two: The "mozilla.org" product, "CVS Account Requests" component requires users to vouch for other users requesting CVS access. A "vouch" flag type would work well in this situation, but only if it can be restricted to that component. Some Mozilla modules, like the JS Engine, no longer require super-review, so components in Bugzilla specific to those modules shouldn't display the "super-review" flag. > This particular specificity is causing problems (see the bug I cited > earlier.) Not at all. There's no reason why flags should have to be confirmed. The current system, which works just like the system it replaced (attachment statuses), works fine: either the flag type exists in the new product/component combination, in which case the flag remains on the bug, or it doesn't, in which case the flag gets deleted. Nothing more complicated needs to be implemented, particularly not an additional confirmation screen, since 1. repeatedly requesting confirmation from the user is frustratingly bad UI design (we should be getting rid of our current confirmation screen, with JS if necessary, not adding to it); 2. it's obvious a user wants consistent bug data when moving a bug to a new product/component; 3. and the likelihood of a user canceling a move because flags would be deleted is incredibly minimal. Good UI design should assume users intend to do what they ask to do and what they do most of the time, while providing a way for users to undo their action in the rare case when the UI guesses wrong, which is what the current system provides. > Indeed. My proposal was not to eliminate global parameters :-) It was > more to suggest that we make "per-product" and "global" the only two > valid values for a specificity. And I am (once again) dismayed at the Bugzilla community's proclivity to establish rules for Bugzilla development whose significant effect will be to make it unnecessarily less flexible. -myk From kiko at async.com.br Thu Oct 24 00:52:31 2002 From: kiko at async.com.br (Christian Reis) Date: Wed, 23 Oct 2002 21:52:31 -0300 Subject: Granularity In-Reply-To: <3DB73EF0.6080106@mozilla.org>; from myk@mozilla.org on Wed, Oct 23, 2002 at 05:29:36PM -0700 References: <3DAEF29F.8010006@mozilla.org> <3DB4A639.4050609@mozilla.org> <3DB6E0A9.9000806@mozilla.org> <3DAEF29F.8010006@mozilla.org> <3DB73EF0.6080106@mozilla.org> Message-ID: <20021023215231.B10080@blackjesus.async.com.br> On Wed, Oct 23, 2002 at 05:29:36PM -0700, Myk Melez wrote: > Gervase Markham wrote: > > > Are you talking about flag types here? Where is the demonstrated need > > for component-level specificity? > > There are (at least) two: > > The "mozilla.org" product, "CVS Account Requests" component requires > users to vouch for other users requesting CVS access. A "vouch" flag > type would work well in this situation, but only if it can be restricted > to that component. > > Some Mozilla modules, like the JS Engine, no longer require > super-review, so components in Bugzilla specific to those modules > shouldn't display the "super-review" flag. To chip in, these are quite valid usage scenarios, and we definitely should accomodate this. The problem with them is just thinking up a way to make both the UI and the backend unhorrible, but that shouldn't be a reason to say no to them. > > Indeed. My proposal was not to eliminate global parameters :-) It was > > more to suggest that we make "per-product" and "global" the only two > > valid values for a specificity. > > And I am (once again) dismayed at the Bugzilla community's proclivity to > establish rules for Bugzilla development whose significant effect will > be to make it unnecessarily less flexible. C'mon Myk, it's just normal feature discussion, don't be like that, we get your point :) Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From matty at chariot.net.au Thu Oct 24 06:57:27 2002 From: matty at chariot.net.au (MattyT) Date: 24 Oct 2002 16:27:27 +0930 Subject: Granularity In-Reply-To: <3DAEF29F.8010006@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> Message-ID: <1035442649.1168.14.camel@megagerbil> On Fri, 2002-10-18 at 02:55, Gervase Markham wrote: > This one's about "granularity" - at what levels should you be able to > configure Bugzilla to do different things? Currently, for example, you > define voting preferences on a per-product basis, whereas the mail > formats are global. We have a number of features coming up, such as > custom fields, for which a granularity will also have to be chosen. What really concerns me here is not the per-component issue, but the fact that we're discussing it *after* it's been checked in. And this is hardly the first time it's happened for me. Currently everyone is working on their own enhancements, and they only get one review. This means a large number of people are potentially in the dark about the implementation of features, and complaints arise when it's essentially too late. Many freed software projects have a single mind who ultimately controls what goes in and what doesn't - Linux for example. We don't have this, Dave probably does not have the time to design review all patches. But it's still important that we have vision and don't let Bugzilla become any more crazy and unorthogonal than it already is in some places. What I think needs to be done, is to have ALL enhancements thoroughly summarised and the summary posted to this list. If we do this, people can easily see the issues, without irrelevant issues complicating the main issues. If no replies come in, that can be taken as implicit approval, and people won't be able to complain they weren't informed. We have certainly done this sort of thing before, but not for everything (or even most things), and I think we should expect it to be. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From justdave at syndicomm.com Thu Oct 24 07:59:50 2002 From: justdave at syndicomm.com (David Miller) Date: Thu, 24 Oct 2002 03:59:50 -0400 Subject: Granularity In-Reply-To: <1035442649.1168.14.camel@megagerbil> References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> Message-ID: On 10/24/02 4:27 PM +0930, MattyT wrote: > Many freed software projects have a single mind who ultimately controls > what goes in and what doesn't - Linux for example. We don't have this, > Dave probably does not have the time to design review all patches. But > it's still important that we have vision and don't let Bugzilla become > any more crazy and unorthogonal than it already is in some places. Actually, I probably do have time for that now... seeing as my paid day-job is actually Bugzilla now. :) How about if we require check-in approval now. That won't count as a review, because I have enough development stuff I have to worry about with my own patches I'm working on to spend major time reviewing things, but as a "yes, this feature has been approved for adding to Bugzilla". With the loss of a second-review in most cases, this is probably a good idea. I also like the idea of posting the idea here to get feedback from people before it gets checked in. If there aren't major objections to the above, I'll file a bug on b.m.o in the next day or two to get a "has-approval" flag added for the Bugzilla product, and we'll proceed that way. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bbaetz at student.usyd.edu.au Thu Oct 24 08:20:42 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 24 Oct 2002 18:20:42 +1000 (EST) Subject: Granularity In-Reply-To: Message-ID: On Thu, 24 Oct 2002, David Miller wrote: > How about if we require check-in approval now. That won't count as a > review, because I have enough development stuff I have to worry about with > my own patches I'm working on to spend major time reviewing things, but as > a "yes, this feature has been approved for adding to Bugzilla". With the > loss of a second-review in most cases, this is probably a good idea. 'eww' :) We do require 2 reviews for schema changes, and the request stuff certainly got at least 2 reviews, with several people looking over it. I still don't see a problem with per-component stuff for this. The problem with moving between products/components was noted _before_ checkin, and allowed to go through since the current code didn't handle it, ie it wasn't a regression. You'll only need two screens when the flag isn't present in the new thing _and_ is set, and by the time a cvs account request has an 'account created' flag, one would hope that it was in the correct component. I really don't see this as a big deal Bradley From matty at chariot.net.au Thu Oct 24 09:21:52 2002 From: matty at chariot.net.au (MattyT) Date: 24 Oct 2002 18:51:52 +0930 Subject: Granularity In-Reply-To: References: Message-ID: <1035451313.1168.19.camel@megagerbil> On Thu, 2002-10-24 at 17:50, Bradley Baetz wrote: > We do require 2 reviews for schema changes, and the request stuff > certainly got at least 2 reviews, with several people looking over it. I > still don't see a problem with per-component stuff for this. The problem > with moving between products/components was noted _before_ checkin, and > allowed to go through since the current code didn't handle it, ie it > wasn't a regression. There's no call to start worrying about attachment statuses. All that's necessary is to post notification here. And as for per-component, I don't recall having heard of it, so it can't have been raised to much. I don't read *every* message, but if there was a thread for each enhancement design, it would go a long way to ensuring everyone knows about everything. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From kiko at async.com.br Thu Oct 24 13:16:46 2002 From: kiko at async.com.br (Christian Reis) Date: Thu, 24 Oct 2002 10:16:46 -0300 Subject: Granularity In-Reply-To: <1035442649.1168.14.camel@megagerbil>; from matty@chariot.net.au on Thu, Oct 24, 2002 at 04:27:27PM +0930 References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> Message-ID: <20021024101646.C384@blackjesus.async.com.br> On Thu, Oct 24, 2002 at 04:27:27PM +0930, MattyT wrote: > What I think needs to be done, is to have ALL enhancements thoroughly > summarised and the summary posted to this list. If we do this, people > can easily see the issues, without irrelevant issues complicating the > main issues. If no replies come in, that can be taken as implicit > approval, and people won't be able to complain they weren't informed. That's certainly a good idea. I'd suggest us using the following rule-of-thumb: if the UI is going to be visibly changed (beyond typos, cosmetic fixes and LABEL additions), or if a major policy is to be set in code, it should be at least announced here. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From gerv at mozilla.org Thu Oct 24 13:31:26 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Oct 2002 14:31:26 +0100 Subject: Bad email addresses Message-ID: <3DB7F62E.2060809@mozilla.org> b.m.o. recently created a whole load of layout components, with default assignees like: "other at layout.bugs" Is this going to be a performance problem, because of the dodgy domain and bounced mails? (It does seem that b.m.o. is moving towards mpt's suggestion of not having default assignees...) Gerv From bbaetz at student.usyd.edu.au Thu Oct 24 13:34:10 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 24 Oct 2002 23:34:10 +1000 (EST) Subject: Bad email addresses In-Reply-To: <3DB7F62E.2060809@mozilla.org> Message-ID: On Thu, 24 Oct 2002, Gervase Markham wrote: > b.m.o. recently created a whole load of layout components, with default > assignees like: > "other at layout.bugs" > > Is this going to be a performance problem, because of the dodgy domain > and bounced mails? They were meant to be added to data/nomail, AIUI. Bradley From myk at mozilla.org Thu Oct 24 20:48:18 2002 From: myk at mozilla.org (Myk Melez) Date: Thu, 24 Oct 2002 13:48:18 -0700 Subject: Granularity In-Reply-To: <3DAEF29F.8010006@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> Message-ID: <3DB85C92.4050909@mozilla.org> MattyT wrote: >What really concerns me here is not the per-component issue, but the >fact that we're discussing it *after* it's been checked in. And this is >hardly the first time it's happened for me. > It's common for me, too, but that's the price of working for a large, active project and not spending my life reading bug mail. I regularly notice check-ins with flaws I would have corrected, but the patches are almost always good enough (TM), and I'd rather they go in than be shunted through another bottleneck that I still won't have enough time to keep up with. >Currently everyone is working on their own enhancements, and they only >get one review. This means a large number of people are potentially in >the dark about the implementation of features, and complaints arise when >it's essentially too late. > Even patches that only need one review frequently get several sets of experienced eyes on them (and lack of a comment doesn't mean lack of attention). It doesn't matter how many people are in the dark as long as a sufficient number aren't, which could be as few as one if that person is an accomplished Bugzilla hacker. >Many freed software projects have a single mind who ultimately controls >what goes in and what doesn't - Linux for example. We don't have this, >Dave probably does not have the time to design review all patches. But >it's still important that we have vision and don't let Bugzilla become >any more crazy and unorthogonal than it already is in some places. > I agree, but our code quality has been consistently increasing, so I don't think we have a "crazy and unorthogonal" problem, and making flags component-specific certainly isn't an example of it, since intentional deviation from a norm for a good reason is a good thing. >What I think needs to be done, is to have ALL enhancements thoroughly >summarised and the summary posted to this list. > In other words, design by committee. No thanks. >We have certainly done this sort of thing before, but not for everything >(or even most things), and I think we should expect it to be. > > I disagree. Design discussions on this list have had some very bad results, f.e. the "sending mail" patch which got bogged down on design so much that nothing has been done, even though all the proposed solutions were good enough and any of them would have been better than no change at all, which is what we have now. I'd much rather have Dave approve patches or delegate such approval to the component owners, with discussions on the list reserved for cases where developers need help or can't agree. -myk From myk at mozilla.org Thu Oct 24 21:45:35 2002 From: myk at mozilla.org (Myk Melez) Date: Thu, 24 Oct 2002 14:45:35 -0700 Subject: upgrading b.m.o; developer's release Message-ID: <3DB869FF.8090707@mozilla.org> I'd like to upgrade b.m.o with the Bugzilla tip in a couple of weeks (ideally Friday, November 8, 6:00pm PDT). Also, it's been a few months since the 2.16 release, about time for us to do a developer's release. It would be nice if we could line these up. How about generating a short list of things we want in for the developer's release and then freezing the trunk to all except those fixes for about a week before the upgrade (i.e. by Friday, November 1)? Ideally we'd have everything in before that date so we have a week to test the trunk before it goes into production on b.m.o. Also ideally we'd release the developer's release a few days before b.m.o upgrades so other installations have a chance to shake out some of the regressions first. So the two questions are: 1. Does this sound like a good plan? 2. What should be on the short list? I'd like: my request tracker regressions and minor enhancements bbaetz's replication work gerv's performance improvements not_erik's user wildcard patch (Yes, I know a lot of these depend on my testing, review, and coding; I've been busy on another project with a deadline of this week, but now that the other project is over I have time again and am back on the ball.) -myk From bugreport at peshkin.net Thu Oct 24 21:57:03 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 24 Oct 2002 14:57:03 -0700 Subject: upgrading b.m.o; developer's release References: <3DB869FF.8090707@mozilla.org> Message-ID: <3DB86CAF.9090205@peshkin.net> Myk Melez wrote: > > > 1. Does this sound like a good plan? Absolutely! > > 2. What should be on the short list? I'd like: > > my request tracker regressions and minor enhancements > bbaetz's replication work > gerv's performance improvements > not_erik's user wildcard patch > I really think you will want bug 127200 for BMO especially. The fix for VERY slow queries on users commenting or CCd on bugs. http://bugzilla.mozilla.org/show_bug.cgi?id=127200 -Joel From bugreport at peshkin.net Fri Oct 25 04:49:17 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 24 Oct 2002 21:49:17 -0700 Subject: RFC: Email address privacy Message-ID: <3DB8CD4D.4040407@peshkin.net> Proposal Circulated for comments: (See http://bugzilla.mozilla.org/show_bug.cgi?id=145499 for details) Sites providing support to multiple customers in competition with each other require the ability to prevent the customers from seeing the email addresses of other customers. This applies to the display of bugs, the display of email addresses during processing, the contents of the email, and the inclusion of users as members of dropdown lists, matches of users by wildcard or substring. The same feature could also be used to prevent the display of email addresses to non-logged-in users. There are several possible mechanisms proposed in bug 145499. The most promising of these permits a user to be placed in a special group that causes that user to be invisible to any user who does is not a member of either the same group or another group that has been granted the right to "see" the user's group. For example... fred at bugzilla.org justdave at bugzilla.org myk at mozilla.org Are all members of group "bugzillacore" harry at tinyco.com larry at tinyco.com darrell at tinyco.com Are all members of group "tinyco" john at werty.net al at home.com tom at fred.net Are all members of group "netizens" Group tinyco and netizens are each marked as being required for mail visibility. Group netizens is visible by group bugzillacore Group tinyco is visible by group bugzillacore As a result of this, the bugzillacore members can see everyone bugzillacore and tinyco members can see tinyco members bugzillacore and netizens members can see netizens members Any other users can see bugzillacore members and any other users not in tinyco or netizens. Please provide any feedback on this concept to this list or on the bug. In particular, what params should control this.... a) enable/disable the entire feature? b) apply feature to all mention of addresses or only in choices offerred by matching in flags, wildcards, and dropdowns? Thanks, -Joel From matty at chariot.net.au Fri Oct 25 06:51:05 2002 From: matty at chariot.net.au (MattyT) Date: 25 Oct 2002 16:21:05 +0930 Subject: Granularity In-Reply-To: <3DB85C92.4050909@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB85C92.4050909@mozilla.org> Message-ID: <1035528676.12904.17.camel@megagerbil> On Fri, 2002-10-25 at 06:18, Myk Melez wrote: >> We have certainly done this sort of thing before, but not for everything >> (or even most things), and I think we should expect it to be. > I disagree. Design discussions on this list have had some very bad > results, f.e. the "sending mail" patch which got bogged down on design > so much that nothing has been done, even though all the proposed > solutions were good enough and any of them would have been better than > no change at all, which is what we have now. I fail to see how this justifies not receiving peer review. Peer review is at the core of the good volunteer projects and is why they produce good software. The logical extension of your argument is to never talk about designs at all, since someone might complain and bog the bug down. It is not "design by committee" if someone holds a big stick and is willing to use it quickly. You also have not offered any proof that we are worse off in the long run through having the discussion on mail, even if it did get bogged down for a while. When things get "shunted through", you often are sacrificing your long term quality for short term gains. If Bugzilla had been designed from the start to be templatised, internationalised, fully field value customisable, run in taint mode, back end separated, blah blah blah, we would have been where we are today a lot earlier. Obviously there were time constraints placed on Terry by mozilla.org that led to these decisions. But most of us now are individual developers who don't have to continue to make these sorts of decisions. A little time invested now pays off big in the long run. Also note that you're much more likely to notice deadlocked design discussions on this list because historically they're generally already deadlocked by the time they get onto the list, as they have started on IRC or on bmo, and escalated. They're also longer, more memorable threads because of the argument. Hence I think the argument factor is quite an exaggeration. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From horiuchi at pb.jp.nec.com Fri Oct 25 08:47:53 2002 From: horiuchi at pb.jp.nec.com (HORIUCHI Takahiko) Date: Fri, 25 Oct 2002 17:47:53 +0900 (JST) Subject: Japanese and Chinese characters in same DB In-Reply-To: <3DB4A22B.4010405@mozilla.org> References: <20021017.215505.40720243.horiuchi@pb.jp.nec.com> <3DB4A22B.4010405@mozilla.org> Message-ID: <20021025.174753.12335577.horiuchi@pb.jp.nec.com> > >So, I want ask you bugzilla experts. Is it dangerous to mix > >different encodings in same MySQL database, or will it work > >fine in some degree? > > > There's some evidence that it works and some issues with Bugzilla that > may need to be resolved for it to work better (in particular bug > 126266). One suggestion I have heard is that if you are starting with a > new Bugzilla installation and are willing to enter everything in Unicode > you can set the default charset for all Bugzilla pages accordingly and > not have any problems at all. Myk, we followed your suggestion. We specified encoding as "charset=UTF-8", and add one routine to transform raw UTF-8 subject to MIME encoded subject. It works very fine. Next week, we'll clear MySQL DB. Thanks. ~~~~ HORIUCHI Takahiko // NEC Informatec Systems [horiuchi at pb.jp.nec.com] // 2nd. Business Solutions / 1st IT division // 03-5232-6527 (8-216-564) From preed at sigkill.com Fri Oct 25 09:00:43 2002 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 25 Oct 2002 02:00:43 -0700 (PDT) Subject: Email Notification Bugs Message-ID: Gang: So, justdave recently asked me what rock I've been under, and the answer is: it's called fall quarter of your senior year in college. But, Bugzilla develpment stops for no one, as it should be. There are two huge email notification bugs that lots of people would like to see fixed... and I mean lots: * the general "Make BZ not rely on sendmail anymore, and not suck"/84876 (God bless that bug) bug * the "Processmail as a package"/124174 bug I have a limited time schedule, but if I can get quick feedback/testing/reviews on patches over the period of, say, a weekend, I can get these bugs checked in. Optimally, I'd like this code to be (generally) reviewed by justdave, joel, bbaetz, gerv, and myk. So: is any weekend better than any other weekend, and will you all be around in the next few weekends (this upcoming weekend, as in tomorrow, I might have some time available to push one of these to checkin). Thoughts on my plan? Ideas? Complaints? Insults? Later, Paul ----------------------------------------------------------------------- J. Paul Reed preed at sigkill.com || web.sigkill.com/preed Wait, stop! We can outsmart those dolphins. Don't forget: we invented computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory hole, *and* the pudding cup! -- Homer Simpson, Tree House of Horror XI From myk at mozilla.org Fri Oct 25 09:53:03 2002 From: myk at mozilla.org (Myk Melez) Date: Fri, 25 Oct 2002 02:53:03 -0700 Subject: Granularity In-Reply-To: <3DAEF29F.8010006@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> <3DB4A639.4050609@mozilla.org> <3DB6E0A9.9000806@mozilla.org> <3DAEF29F.8010006@mozilla.org> <3DB73EF0.6080106@mozilla.org> <20021023215231.B10080@blackjesus.async.com.br> Message-ID: <3DB9147F.8050409@mozilla.org> Christian Reis wrote: >C'mon Myk, it's just normal feature discussion, don't be like that, we >get your point :) > I'm *shocked* -- *shocked* -- to *find* *gambling* is going on in here! ;-) -myk From bbaetz at student.usyd.edu.au Fri Oct 25 10:01:01 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Fri, 25 Oct 2002 20:01:01 +1000 (EST) Subject: Granularity In-Reply-To: <3DB9147F.8050409@mozilla.org> Message-ID: On Fri, 25 Oct 2002, Myk Melez wrote: > I'm *shocked* -- *shocked* -- to *find* *gambling* is going on in here! ;-) You mean the internet can be used for something else? > -myk Bradley From bbaetz at student.usyd.edu.au Fri Oct 25 10:02:10 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Fri, 25 Oct 2002 20:02:10 +1000 (EST) Subject: Email Notification Bugs In-Reply-To: Message-ID: Well, my rock is called 'honors thesis' :) Seriously, though, the second of your bugs (moving processmail to a package) would save us about 1 second per call, and its relatively free of contraversy, so that may be the better one to start with. Bradley From preed at sigkill.com Fri Oct 25 10:07:35 2002 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 25 Oct 2002 03:07:35 -0700 (PDT) Subject: Email Notification Bugs In-Reply-To: Message-ID: On Fri, 25 Oct 2002, Bradley Baetz wrote: > Seriously, though, the second of your bugs (moving processmail to a > package) would save us about 1 second per call, and its relatively free > of contraversy, so that may be the better one to start with. Good call. I'll work on that one this weekend, assuming everyone else can be around to get it checked in. Later, Paul ----------------------------------------------------------------------- J. Paul Reed preed at sigkill.com || web.sigkill.com/preed Wait, stop! We can outsmart those dolphins. Don't forget: we invented computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory hole, *and* the pudding cup! -- Homer Simpson, Tree House of Horror XI From gerv at mozilla.org Fri Oct 25 10:17:57 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 11:17:57 +0100 Subject: Email Notification Bugs In-Reply-To: References: Message-ID: <3DB91A55.5090805@mozilla.org> Bradley Baetz wrote: > Well, my rock is called 'honors thesis' :) > > Seriously, though, the second of your bugs (moving processmail to a > package) would save us about 1 second per call, and its relatively free of > contraversy, so that may be the better one to start with. Ah. I was about to suggest the first one, because it blocks a load of other mail work, particularly templatisation :-) But I guess perf is more important right now. Gerv From kiko at async.com.br Fri Oct 25 10:29:42 2002 From: kiko at async.com.br (Christian Reis) Date: Fri, 25 Oct 2002 07:29:42 -0300 Subject: Granularity In-Reply-To: <1035528676.12904.17.camel@megagerbil>; from matty@chariot.net.au on Fri, Oct 25, 2002 at 04:21:05PM +0930 References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB85C92.4050909@mozilla.org> <1035528676.12904.17.camel@megagerbil> Message-ID: <20021025072942.S942@blackjesus.async.com.br> On Fri, Oct 25, 2002 at 04:21:05PM +0930, MattyT wrote: > If Bugzilla had been designed from the start to be templatised, > internationalised, fully field value customisable, run in taint mode, > back end separated, blah blah blah, we would have been where we are Cross-database... Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From kiko at async.com.br Fri Oct 25 14:43:21 2002 From: kiko at async.com.br (Christian Reis) Date: Fri, 25 Oct 2002 11:43:21 -0300 Subject: Comment format for CVS -> Bugzilla comment gateway Message-ID: <20021025114321.D5648@blackjesus.async.com.br> Hi there, I'm working on a loginfo script that will add a comment to Bugzilla every time a CVS commit is done with a bug number cited. I was wondering what sort of information people would like to see in the comment. I am thinking to add: - A short text explaining a commit was done (should I use a standard format like "CVS Checkin:" instead of a line of text?) - The checkin comment - author (pity I can't get email, right? or can I..) - The files touched by the checkins, optionally being links to Bonsai diffs Anything else? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From kiko at async.com.br Fri Oct 25 14:48:48 2002 From: kiko at async.com.br (Christian Reis) Date: Fri, 25 Oct 2002 11:48:48 -0300 Subject: Comments for CVS -> Bugzilla Gateway part 2 Message-ID: <20021025114848.E5648@blackjesus.async.com.br> I forgot; The bug I am working with is http://bugzilla.mozilla.org/show_bug.cgi?id=129765 The second issue is: how do we allow specifying the bug # in the CVS checkin comment? Timeless has suggested the formats "bug 23222" "bug #2323" "bug# 33432" I have seen "b=23232" and "b#=23232" on Mozilla bonsai. Anybody have any other formats they think are likely? Should we support b=*? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From preed at sigkill.com Fri Oct 25 14:58:35 2002 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 25 Oct 2002 07:58:35 -0700 (PDT) Subject: Comment format for CVS -> Bugzilla comment gateway In-Reply-To: <20021025114321.D5648@blackjesus.async.com.br> Message-ID: On Fri, 25 Oct 2002, Christian Reis wrote: > - author (pity I can't get email, right? or can I..) Well, the author of the patch is *typically* the person checking it in, although not always (if people don't have checkin privs yet, or someone else takes over the patch to drive the checkin). You could make it known throughout the bmo (and other installations that wanted to use this feature) community that if you want this feature to work, and you didn't write the patch, you have to mark it up like author=email_address or patch=email_address. I've seen both. Although it's not 100% necessary within Bugzilla, it would be nice to know a couple of other things: -- Under which approval the patch was checked in, if that's necessary -- Which attachment ID was checked in I don't know how you'd do the latter. The former could be accomplished easily with a hash of regexs -> strings, ala: 'p=($email_address_regex)' => 'Patch author: $1', 'sr=$email_address_regex)' => "Senior review: $1', etc. This would also allow some level of customization for other sites using other systems to track patches (one project I work on uses patch=address/r=address (since there's only one r= needed). Later, Paul ----------------------------------------------------------------------- J. Paul Reed preed at sigkill.com || web.sigkill.com/preed Wait, stop! We can outsmart those dolphins. Don't forget: we invented computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory hole, *and* the pudding cup! -- Homer Simpson, Tree House of Horror XI From gerv at mozilla.org Fri Oct 25 15:02:36 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 16:02:36 +0100 Subject: LDP Bugzilla Guide Message-ID: <3DB95D0C.5040809@mozilla.org> The Bugzilla Guide up on the Linux Documentation Project is for 2.12. We need to either update it or remove it. Is barnboy listening? :-) Gerv From bugreport at peshkin.net Fri Oct 25 14:50:26 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 25 Oct 2002 07:50:26 -0700 Subject: Major groups system change landing soon Message-ID: <3DB95A32.7000104@peshkin.net> All: The next major change in the group system should be landing shortly. The existing behaviors of product groups will emulate the behavior of the old usebuggroups and usebuggroupsentry by default, but it becomes possible to define a set of controls for each product specifying the relationship of that product to each group. By default, these controls will automatically set themselves to match the old installation's product group's behavior, so it is possible to completely ignore this capability and proceed as before. However, after bug 147275 lands, the controls sexplained below are available. It should be possible for many sites to avoid the need for users to ever see a group checkbox. Please comment here or on the bug and definitely please test the patch. If any group has *Entry* selected, then this product will restrict bug entry to only those users who are members of all the groups with entry selected. If any group has *Canedit* selected, then this product will be read-only for any users who are not members of all of the groups with Canedit selected. The *MemberControl* and *OtherControl* fields indicate which bugs will be placed in this group according to the following definitions. MemberControl OtherControl Interpretation NA NA Bugs in this product are never associated with this group. Shown NA Bugs in this product are permitted to be restricted to this group. Users who are a member of this group will be able to place bugs in this group. Shown Shown Bugs in this product can be placed in this group by anyone with permission to edit the bug even if they are not a member of this group. Shown Default Bugs in this product can be placed in this group by anyone with permission to edit the bug even if they are not a member of this group. Non-members place bugs in this group by default. Shown Mandatory Bugs in this product are permitted to be restricted to this group. Users who are a member of this group will be able to place bugs in this group.Non-members will be forced to restrict bugs to this group when they initially enter a bug in this product. Default NA Bugs in this product are permitted to be restricted to this group and are placed in this group by default.Users who are a member of this group will be able to place bugs in this group. Default Default Bugs in this product are permitted to be restricted to this group and are placed in this group by default.Users who are a member of this group will be able to place bugs in this group. Non-members will be able to restrict bugs to this group on entry and will do so by default Default Mandatory Bugs in this product are permitted to be restricted to this group and are placed in this group by default.Users who are a member of this group will be able to place bugs in this group. Non-members will be forced to place bugs in this group on entry. Mandatory Mandatory Bugs in this product are required to be restricted to this group. Users are not given any option. -Joel -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Oct 25 15:06:00 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 16:06:00 +0100 Subject: Comment format for CVS -> Bugzilla comment gateway In-Reply-To: <20021025114321.D5648@blackjesus.async.com.br> References: <20021025114321.D5648@blackjesus.async.com.br> Message-ID: <3DB95DD8.5040601@mozilla.org> Christian Reis wrote: > Hi there, > > I'm working on a loginfo script that will add a comment to Bugzilla > every time a CVS commit is done with a bug number cited. I was wondering > what sort of information people would like to see in the comment. I am > thinking to add: > > - A short text explaining a commit was done (should I use a standard > format like "CVS Checkin:" instead of a line of text?) > - The checkin comment > - author (pity I can't get email, right? or can I..) If there's a mapping from cvs account names to email addresses, like on mozilla.org, then yes :-) > - The files touched by the checkins, optionally being links to Bonsai > diffs Making them links is difficult; currently, the only way to do this is to print the entire URL and get it linkified, but that would be Really Ugly. Something like: Related CVS checkin by foo at bar.com: "Bug 123456: Fix the foo generator. Patch by gerv; r=bbaetz." File List: template/en/default/index.html.tmpl (1.33) template/en/default/sidebar.xul.tmpl (1.1) Gerv From kiko at async.com.br Fri Oct 25 15:22:54 2002 From: kiko at async.com.br (Christian Reis) Date: Fri, 25 Oct 2002 12:22:54 -0300 Subject: Comment format for CVS -> Bugzilla comment gateway In-Reply-To: <3DB95DD8.5040601@mozilla.org>; from gerv@mozilla.org on Fri, Oct 25, 2002 at 04:06:00PM +0100 References: <20021025114321.D5648@blackjesus.async.com.br> <3DB95DD8.5040601@mozilla.org> Message-ID: <20021025122254.G5648@blackjesus.async.com.br> On Fri, Oct 25, 2002 at 04:06:00PM +0100, Gervase Markham wrote: > Related CVS checkin by foo at bar.com: > "Bug 123456: Fix the foo generator. Patch by gerv; r=bbaetz." Use quotes? > File List: > template/en/default/index.html.tmpl (1.33) > template/en/default/sidebar.xul.tmpl (1.1) What about removed/added files? (REMOVED) and (ADDED)? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From bugreport at peshkin.net Fri Oct 25 15:17:52 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 25 Oct 2002 08:17:52 -0700 Subject: Comments for CVS -> Bugzilla Gateway part 2 References: <20021025114848.E5648@blackjesus.async.com.br> Message-ID: <3DB960A0.3060104@peshkin.net> Christian Reis wrote: > > >The second issue is: how do we allow specifying the bug # in the CVS >checkin comment? Timeless has suggested the formats > >"bug 23222" "bug #2323" "bug# 33432" > >I have seen > >"b=23232" and "b#=23232" on Mozilla bonsai. Anybody have any other >formats they think are likely? Should we support b=*? > > > We currently require every commit to have LOG: 23232 or MERGE: anything or else the commit is rejected. This information should not be in a comment. It should be in another table and provided to show_bug in a manner similar to the attachment list. This allows queries like.... "show all bugs touching myfunctions.c" It also facilitates dumping a list of bugs between CVS tag BUGZILLA_2_17_1 and BUGZILLA_2_18 -Joel From gerv at mozilla.org Fri Oct 25 15:33:41 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 16:33:41 +0100 Subject: Comment format for CVS -> Bugzilla comment gateway In-Reply-To: <20021025122254.G5648@blackjesus.async.com.br> References: <20021025114321.D5648@blackjesus.async.com.br> <3DB95DD8.5040601@mozilla.org> <20021025122254.G5648@blackjesus.async.com.br> Message-ID: <3DB96455.3060909@mozilla.org> Christian Reis wrote: > On Fri, Oct 25, 2002 at 04:06:00PM +0100, Gervase Markham wrote: > >>Related CVS checkin by foo at bar.com: >>"Bug 123456: Fix the foo generator. Patch by gerv; r=bbaetz." > > Use quotes? Yeah, why not? It makes it clear which bit is the CVS comment. >>File List: >>template/en/default/index.html.tmpl (1.33) >>template/en/default/sidebar.xul.tmpl (1.1) > > What about removed/added files? (REMOVED) and (ADDED)? (removed) and (added) :-) Gerv From gerv at mozilla.org Fri Oct 25 15:34:50 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 16:34:50 +0100 Subject: Comments for CVS -> Bugzilla Gateway part 2 In-Reply-To: <20021025114848.E5648@blackjesus.async.com.br> References: <20021025114848.E5648@blackjesus.async.com.br> Message-ID: <3DB9649A.2060401@mozilla.org> Christian Reis wrote: > The second issue is: how do we allow specifying the bug # in the CVS > checkin comment? Timeless has suggested the formats > > "bug 23222" "bug #2323" "bug# 33432" > > I have seen > > "b=23232" and "b#=23232" on Mozilla bonsai. Anybody have any other > formats they think are likely? Should we support b=*? Whatever format you specify, people will standardise on if you say that this is what's supported. In other words, it's a good way to ensure consistency and conformity among CVS checkin comments, which can only be a good thing. So, for example, you could say that bug references have to start the comment, and have to be of the form: Bug 123456(, Bug 234567)* : ... My argument is, in a nutshell, to be strict rather than liberal in what you accept :-) Gerv From gerv at mozilla.org Fri Oct 25 15:36:19 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 16:36:19 +0100 Subject: Comments for CVS -> Bugzilla Gateway part 2 In-Reply-To: <3DB960A0.3060104@peshkin.net> References: <20021025114848.E5648@blackjesus.async.com.br> <3DB960A0.3060104@peshkin.net> Message-ID: <3DB964F3.4010903@mozilla.org> Joel Peshkin wrote: > Christian Reis wrote: > This information should not be in a comment. It should be in another > table and provided to show_bug in a manner similar to the attachment > list. This allows queries like.... "show all bugs touching myfunctions.c" > > It also facilitates dumping a list of bugs between CVS tag > BUGZILLA_2_17_1 and BUGZILLA_2_18 I think that what you suggest is much more than what kiko wants to implement :-) As is said in the bug he is attempting to fix, bug 6422 is for a comprehensive integration, and bug 129765 is for a simple one. Gerv From tara at tequilarista.org Fri Oct 25 16:21:48 2002 From: tara at tequilarista.org (Tara Hernandez) Date: Fri, 25 Oct 2002 09:21:48 -0700 Subject: Comments for CVS -> Bugzilla Gateway part 2 References: <20021025114848.E5648@blackjesus.async.com.br> <3DB9649A.2060401@mozilla.org> Message-ID: <3DB96F9C.6020303@tequilarista.org> I still think that within the simplicity of the interim bug fix, there should be a way for an administrator to customize what is parsed in some reasonable way (i.e. other than manually modifying CGI/PL). That way places that already have a checkin standard don't have to change it unnecessarily. -Tara Gervase Markham wrote: > Christian Reis wrote: > >> The second issue is: how do we allow specifying the bug # in the CVS >> checkin comment? Timeless has suggested the formats >> >> "bug 23222" "bug #2323" "bug# 33432" >> >> I have seen >> >> "b=23232" and "b#=23232" on Mozilla bonsai. Anybody have any other >> formats they think are likely? Should we support b=*? > > > Whatever format you specify, people will standardise on if you say > that this is what's supported. In other words, it's a good way to > ensure consistency and conformity among CVS checkin comments, which > can only be a good thing. > > So, for example, you could say that bug references have to start the > comment, and have to be of the form: > Bug 123456(, Bug 234567)* : ... > > My argument is, in a nutshell, to be strict rather than liberal in > what you accept :-) > > Gerv > > ---- > To view or change your list settings, click here: > > > From kiko at async.com.br Fri Oct 25 16:43:10 2002 From: kiko at async.com.br (Christian Reis) Date: Fri, 25 Oct 2002 13:43:10 -0300 Subject: Comments for CVS -> Bugzilla Gateway part 2 In-Reply-To: <3DB96F9C.6020303@tequilarista.org>; from tara@tequilarista.org on Fri, Oct 25, 2002 at 09:21:48AM -0700 References: <20021025114848.E5648@blackjesus.async.com.br> <3DB9649A.2060401@mozilla.org> <3DB96F9C.6020303@tequilarista.org> Message-ID: <20021025134310.I5648@blackjesus.async.com.br> On Fri, Oct 25, 2002 at 09:21:48AM -0700, Tara Hernandez wrote: > some reasonable way (i.e. other than manually modifying CGI/PL). That > way places that already have a checkin standard don't have to change it Changing a bit in the script's header is not acceptable? You will need to add a password and username somewhere too, you know.. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From preed at sigkill.com Fri Oct 25 17:03:55 2002 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 25 Oct 2002 10:03:55 -0700 (PDT) Subject: Comments for CVS -> Bugzilla Gateway part 2 In-Reply-To: <3DB96F9C.6020303@tequilarista.org> Message-ID: On Fri, 25 Oct 2002, Tara Hernandez wrote: > I still think that within the simplicity of the interim bug fix, there > should be a way for an administrator to customize what is parsed in some > reasonable way (i.e. other than manually modifying CGI/PL). That way > places that already have a checkin standard don't have to change it > unnecessarily. So... in other words, a hash of regexs that map to messages to put in the generated Bugzilla comment... Later, Paul ----------------------------------------------------------------------- J. Paul Reed preed at sigkill.com || web.sigkill.com/preed Wait, stop! We can outsmart those dolphins. Don't forget: we invented computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory hole, *and* the pudding cup! -- Homer Simpson, Tree House of Horror XI From myk at mozilla.org Fri Oct 25 17:16:06 2002 From: myk at mozilla.org (Myk Melez) Date: Fri, 25 Oct 2002 10:16:06 -0700 Subject: Comments for CVS -> Bugzilla Gateway part 2 In-Reply-To: <20021025114848.E5648@blackjesus.async.com.br> References: <20021025114848.E5648@blackjesus.async.com.br> <3DB9649A.2060401@mozilla.org> <3DB96F9C.6020303@tequilarista.org> <20021025134310.I5648@blackjesus.async.com.br> Message-ID: <3DB97C56.60509@mozilla.org> Christian Reis wrote: >On Fri, Oct 25, 2002 at 09:21:48AM -0700, Tara Hernandez wrote: > > >>some reasonable way (i.e. other than manually modifying CGI/PL). That >>way places that already have a checkin standard don't have to change it >> >> I agree; it would be very helpful for installations with established standards differing from the default not to have to promulgate an unfamiliar alternative. I can't imagine this is any trouble on the development side of the house. It's a single regexp after all. >Changing a bit in the script's header is not acceptable? You will need >to add a password and username somewhere too, you know.. > That would work, but all three pieces of information seem ripe for putting into a configuration file. -myk From yannick.koehler at colubris.com Fri Oct 25 17:17:06 2002 From: yannick.koehler at colubris.com (Yannick Koehler) Date: Fri, 25 Oct 2002 13:17:06 -0400 Subject: Comments for CVS -> Bugzilla Gateway part 2 In-Reply-To: <3DB9649A.2060401@mozilla.org> References: <20021025114848.E5648@blackjesus.async.com.br> <3DB9649A.2060401@mozilla.org> Message-ID: <200210251317.10321.yannick.koehler@colubris.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le October 25, 2002 11:34 am, Gervase Markham a ?crit: / On October 25, 2002 11:34 am, Gervase Markham wrote: > Christian Reis wrote: > > The second issue is: how do we allow specifying the bug # in the CVS > > checkin comment? Timeless has suggested the formats > > > > "bug 23222" "bug #2323" "bug# 33432" > > > > I have seen > > > > "b=23232" and "b#=23232" on Mozilla bonsai. Anybody have any other > > formats they think are likely? Should we support b=*? > > Whatever format you specify, people will standardise on if you say that > this is what's supported. In other words, it's a good way to ensure > consistency and conformity among CVS checkin comments, which can only be > a good thing. > > So, for example, you could say that bug references have to start the > comment, and have to be of the form: > Bug 123456(, Bug 234567)* : ... > > My argument is, in a nutshell, to be strict rather than liberal in what > you accept :-) It would be nice that the cvs branch name in which the commit is done appears inside the bugzilla comment as well. - -- Yannick Koehler -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9uXyUfuKOJNEyL1URAqWgAJ9zMz0VQYbGMtzKhG13qLxl1Yx0XQCfWI0d qwfcRha2oDK+2qybHZwSSwE= =xvvd -----END PGP SIGNATURE----- From yannick.koehler at colubris.com Fri Oct 25 17:19:21 2002 From: yannick.koehler at colubris.com (Yannick Koehler) Date: Fri, 25 Oct 2002 13:19:21 -0400 Subject: Comments for CVS -> Bugzilla Gateway part 2 In-Reply-To: <3DB96F9C.6020303@tequilarista.org> References: <20021025114848.E5648@blackjesus.async.com.br> <3DB9649A.2060401@mozilla.org> <3DB96F9C.6020303@tequilarista.org> Message-ID: <200210251319.22635.yannick.koehler@colubris.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le October 25, 2002 12:21 pm, Tara Hernandez a ?crit: / On October 25, 2002 12:21 pm, Tara Hernandez wrote: > I still think that within the simplicity of the interim bug fix, there > should be a way for an administrator to customize what is parsed in > some reasonable way (i.e. other than manually modifying CGI/PL). That > way places that already have a checkin standard don't have to change it > unnecessarily. If you start in that direction you will, never meet everyone requirement, make the code bigger and probably make more complex parsing rule than necessary. It is better to define Simple API and have "plumbing" scripts that convert from one to another. That is being seen in most software even XML with XLST goes along this philosophy. KISS - -- Yannick Koehler -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9uX0afuKOJNEyL1URAsdHAJ0WFlYb3fvV1PALvFZgRW6edyfNyACfWM76 Ry8f18AI9PVmEtqlqKuiPsQ= =prmY -----END PGP SIGNATURE----- From tara at tequilarista.org Fri Oct 25 17:42:07 2002 From: tara at tequilarista.org (Tara Hernandez) Date: Fri, 25 Oct 2002 10:42:07 -0700 Subject: Comments for CVS -> Bugzilla Gateway part 2 References: <20021025114848.E5648@blackjesus.async.com.br> <3DB9649A.2060401@mozilla.org> <3DB96F9C.6020303@tequilarista.org> <200210251319.22635.yannick.koehler@colubris.com> Message-ID: <3DB9826F.70608@tequilarista.org> I not sure I understand your thinking. All I'm saying is "don't hardcode into the script whatever mechanism does the final parsing". It has to be done somewhere, just make sure the part of it that's useful is exposed in a usable way. -Tara Yannick Koehler wrote: > >If you start in that direction you will, never meet everyone requirement, make >the code bigger and probably make more complex parsing rule than necessary. >It is better to define Simple API and have "plumbing" scripts that convert >from one to another. That is being seen in most software even XML with XLST >goes along this philosophy. > >KISS > >- -- > >Yannick Koehler >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.6 (GNU/Linux) >Comment: For info see http://www.gnupg.org > >iD8DBQE9uX0afuKOJNEyL1URAsdHAJ0WFlYb3fvV1PALvFZgRW6edyfNyACfWM76 >Ry8f18AI9PVmEtqlqKuiPsQ= >=prmY >-----END PGP SIGNATURE----- > >---- >To view or change your list settings, click here: > > > > > From gerv at mozilla.org Fri Oct 25 17:52:11 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 18:52:11 +0100 Subject: Granularity In-Reply-To: <1035528676.12904.17.camel@megagerbil> References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB85C92.4050909@mozilla.org> <1035528676.12904.17.camel@megagerbil> Message-ID: <3DB984CB.3050607@mozilla.org> > I fail to see how this justifies not receiving peer review. Peer review > is at the core of the good volunteer projects and is why they produce > good software. The logical extension of your argument is to never talk > about designs at all, since someone might complain and bog the bug down. > > It is not "design by committee" if someone holds a big stick and is > willing to use it quickly. What he said :-) This list should be notified, at least, of major upcoming changes, so that those who have the time and inclination can read the bug, provide input, and review the code. IMO, Joel's "groups landing patch" mail is an excellent example of the sort of things we should see :-) Gerv From myk at mozilla.org Fri Oct 25 17:52:57 2002 From: myk at mozilla.org (Myk Melez) Date: Fri, 25 Oct 2002 10:52:57 -0700 Subject: Granularity In-Reply-To: <3DAEF29F.8010006@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB85C92.4050909@mozilla.org> <1035528676.12904.17.camel@megagerbil> Message-ID: <3DB984F9.9050901@mozilla.org> MattyT wrote: >I fail to see how this justifies not receiving peer review. Peer review >is at the core of the good volunteer projects and is why they produce >good software. The logical extension of your argument is to never talk >about designs at all, since someone might complain and bog the bug down. > This has nothing to do with peer review, which I absolutely agree with. It's about whether or not everyone should get involved in each review. >It is not "design by committee" if someone holds a big stick and is >willing to use it quickly. You also have not offered any proof that we >are worse off in the long run through having the discussion on mail, >even if it did get bogged down for a while. > If you agree with my assertion that all the alternatives were at least good enough (and, fwiw, the participants in the debate seemed to feel this way last time I checked with them) and that the fix would be better than not having it, then it's clear that we are worse off now than we would have been if one of those fixes had gone in. >When things get "shunted >through", you often are sacrificing your long term quality for short >term gains. > But I'm not talking about "shunting" anything through at all. I'm talking about patches that get reviewed (sometimes repeatedly) by one or more experienced hackers before going in and that provide significant benefit to the code, even if they sometimes have flaws (which we also didn't catch back when we were doing two reviews). >If Bugzilla had been designed from the start to be templatised, >internationalised, fully field value customisable, run in taint mode, >back end separated, blah blah blah, we would have been where we are >today a lot earlier. > More likely we wouldn't have been anywhere at all (cf: Bugzilla 3.0). Only huge engineering projects (f.e. rockets to the moon) can be built this way, and only by expending an incredible amount of resources beforehand, disproportionately large relative to the size of the project. Bugzilla is certainly getting larger, but it isn't nearly there yet. > Obviously there were time constraints placed on >Terry by mozilla.org that led to these decisions. But most of us now >are individual developers who don't have to continue to make these sorts >of decisions. A little time invested now pays off big in the long run. > I contend that reviewers and regular "viewers" regularly invest that time now, often more than is necessary, to ensure that the code that goes in takes our future plans and current standards into account. Overexuberance in this regard is, in fact, one of the reasons (although not the major one) why our reviews take so dang long. And you also have to consider the law of diminishing returns. There's only so much discussion you can have before it stops being useful and you're better off implementing your current best guess and fixing any problems down the road. >Also note that you're much more likely to notice deadlocked design >discussions on this list because historically they're generally already >deadlocked by the time they get onto the list, as they have started on >IRC or on bmo, and escalated. They're also longer, more memorable >threads because of the argument. Hence I think the argument factor is >quite an exaggeration. > I think an increasingly common case is that someone posts a message and then everyone jumps into the discussion with their opinion. Over time the opinions start to take on weight and harden, and then it becomes too important for everyone's opinion to be taken into account in the final design. The first half of this dynamic--the jumping in with opinions--has already happened today with Christian's CVS integration. Hopefully the second won't. -myk From gerv at mozilla.org Fri Oct 25 18:08:53 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 19:08:53 +0100 Subject: Granularity In-Reply-To: References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> Message-ID: <3DB988B5.7030501@mozilla.org> David Miller wrote: > How about if we require check-in approval now. I think that this is a good idea, if you approve bugs, rather than patches - i.e. you say, at any point in the development, "Yes, this bug needs to be fixed in the way you are outlining", and then we can just get on with it. If it has to wait for review to happen, then it'll be an unnecessary bottleneck. > I also like the idea of posting the idea here to get feedback from people > before it gets checked in. Me too :-) > If there aren't major objections to the above, I'll file a bug on b.m.o in > the next day or two to get a "has-approval" flag added for the Bugzilla > product, and we'll proceed that way. We'll need to wait until we have bug flags, after Nov. 8th, if you take my suggestion above. Gerv From gerv at mozilla.org Fri Oct 25 19:27:12 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 20:27:12 +0100 Subject: [Fwd: Re: Bad email addresses] Message-ID: <3DB99B10.2020107@mozilla.org> Timeless says: -------- Original Message -------- Subject: Re: Bad email addresses Date: Thu, 24 Oct 2002 14:09:32 -0400 From: timeless To: Gervase Markham References: <3DB7F62E.2060809 at mozilla.org> Gervase Markham wrote: > b.m.o. recently created a whole load of layout components, with default > assignees like: > "other at layout.bugs" yes, I did. > Is this going to be a performance problem, because of the dodgy domain > and bounced mails? given that i manually created each account and unchecked every mail option for them, i'd hope not. if it does then something in bugzila is buggy. note that endico claims data/nomail may actually not be working and nobody at mozilla.org is relying on that mechanism. so if there's a problem b.m.o is *already* suffering from it, but will not be suffering from my changes. > (It does seem that b.m.o. is moving towards mpt's suggestion of not > having default assignees...) all of layout is essentially volunteer, they explained this to asa the day he finally yielded. -- as usual, please forward to the list From kiko at async.com.br Fri Oct 25 19:50:27 2002 From: kiko at async.com.br (Christian Reis) Date: Fri, 25 Oct 2002 16:50:27 -0300 Subject: process_bug.cgi as backend and dontchange In-Reply-To: <3DB988B5.7030501@mozilla.org>; from gerv@mozilla.org on Fri, Oct 25, 2002 at 07:08:53PM +0100 References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB988B5.7030501@mozilla.org> Message-ID: <20021025165027.K5648@blackjesus.async.com.br> So, I'm hacking away at this CVS->Bugzilla client. Context: it's a *pure* HTTP client - all it does is connect to process_bug.cgi, and send in a well-formed form that updates a single bug. If I want to add a comment to many bugs, I'll do multiple HTTP requests, no problem. Problem: there is no way to specify dontchange if you are changing a single bug. What I want is to add a single comment - and process_bug wants *all* the fields defined. dontchange would be a nice way to work around that, except for the fact that the tests in process_bug only look at dontchange if it's a multiple bug change. I *think* this could be fixed by changing the way process_bug handles the tests for dontchange. I'll exemplify with a small patch: Index: process_bug.cgi =================================================================== RCS file: /cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v retrieving revision 1.159 diff -u -r1.159 process_bug.cgi --- process_bug.cgi 25 Oct 2002 03:59:28 -0000 1.159 +++ process_bug.cgi 25 Oct 2002 19:42:37 -0000 @@ -199,8 +199,9 @@ "WHERE products.id = bugs.product_id AND bug_id = $::FORM{'id'}"); $::oldproduct = FetchSQLData(); } -if ((($::FORM{'id'} && $::FORM{'product'} ne $::oldproduct) - || (!$::FORM{'id'} && $::FORM{'product'} ne $::FORM{'dontchange'})) + +if (($::FORM{'id'} && $::FORM{'product'} ne $::oldproduct) + && ( $::FORM{'product'} ne $::FORM{'dontchange'}) && CheckonComment( "reassignbycomponent" )) { CheckFormField(\%::FORM, 'product', \@::legal_product); This way, if dontchange is specified, it will simply skip that check. Is that sane? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From myk at mozilla.org Fri Oct 25 20:03:18 2002 From: myk at mozilla.org (Myk Melez) Date: Fri, 25 Oct 2002 13:03:18 -0700 Subject: Granularity In-Reply-To: References: Message-ID: <3DB9A386.5000503@mozilla.org> Bradley Baetz wrote: >On Fri, 25 Oct 2002, Myk Melez wrote: > > > >>I'm *shocked* -- *shocked* -- to *find* *gambling* is going on in here! ;-) >> >> > >You mean the internet can be used for something else? > No, gambling is it. *COUGH!* porn *COUGH!* -myk From kiko at async.com.br Fri Oct 25 20:07:38 2002 From: kiko at async.com.br (Christian Reis) Date: Fri, 25 Oct 2002 17:07:38 -0300 Subject: process_bug.cgi as backend and dontchange In-Reply-To: <20021025165027.K5648@blackjesus.async.com.br>; from kiko@async.com.br on Fri, Oct 25, 2002 at 04:50:27PM -0300 References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB988B5.7030501@mozilla.org> <20021025165027.K5648@blackjesus.async.com.br> Message-ID: <20021025170738.L5648@blackjesus.async.com.br> On Fri, Oct 25, 2002 at 04:50:27PM -0300, Christian Reis wrote: > I *think* this could be fixed by changing the way process_bug handles > the tests for dontchange. I'll exemplify with a small patch: The previous patch, together with this small change in CGI.pl make things work smoothly, but are there evil side-effects? Index: CGI.pl =================================================================== RCS file: /cvsroot/mozilla/webtools/bugzilla/CGI.pl,v retrieving revision 1.187 diff -u -r1.187 CGI.pl --- CGI.pl 17 Oct 2002 04:31:49 -0000 1.187 +++ CGI.pl 25 Oct 2002 19:58:14 -0000 @@ -239,9 +239,10 @@ ) = @_; if ( !defined $formRef->{$fieldname} || - trim($formRef->{$fieldname}) eq "" || + (trim($formRef->{$fieldname}) eq "" || (defined($legalsRef) && - lsearch($legalsRef, $formRef->{$fieldname})<0) ){ + lsearch($legalsRef, $formRef->{$fieldname})<0) ) + && $formRef->{$fieldname} != $formRef->{'dontchange'}) { SendSQL("SELECT description FROM fielddefs WHERE name=" . SqlQuote($fieldname)); my $result = FetchOneColumn(); Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From matthew at barnson.org Fri Oct 25 20:28:42 2002 From: matthew at barnson.org (Matthew P. Barnson) Date: 25 Oct 2002 14:28:42 -0600 Subject: LDP Bugzilla Guide In-Reply-To: <3DB95D0C.5040809@mozilla.org> References: <3DB95D0C.5040809@mozilla.org> Message-ID: <1035577723.25683.21.camel@chandler.int.barnson.org> Yep, let me grab the current revision from CVS and send it in. Should be updated within a day or two! On Fri, 2002-10-25 at 09:02, Gervase Markham wrote: > The Bugzilla Guide up on the Linux Documentation Project is for 2.12. We > need to either update it or remove it. Is barnboy listening? :-) > > Gerv > > ---- > To view or change your list settings, click here: > > -- Matthew P. Barnson Sr. UNIX Systems Administrator DAM Computer Consulting, Inc. "When you cuss, think of us!" "...the general idea that [the Supreme Court ]will restrain itself, despite believing a law is stupid, is a feature, not a bug in our constitutional tradition." -Lawrence Lessig nd 100%". --Penn Jillette one and drive on without guilt! -ccm From gerv at mozilla.org Fri Oct 25 20:46:05 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Oct 2002 21:46:05 +0100 Subject: process_bug.cgi as backend and dontchange In-Reply-To: <3DAEF29F.8010006@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB988B5.7030501@mozilla.org> <20021025165027.K5648@blackjesus.async.com.br> Message-ID: <3DB9AD8D.2070202@mozilla.org> Christian Reis wrote: > So, I'm hacking away at this CVS->Bugzilla client. > > Context: it's a *pure* HTTP client - all it does is connect to > process_bug.cgi, and send in a well-formed form that updates a single > bug. If I want to add a comment to many bugs, I'll do multiple HTTP > requests, no problem. > > Problem: there is no way to specify dontchange if you are changing a > single bug. What I want is to add a single comment - and process_bug > wants *all* the fields defined. dontchange would be a nice way to work > around that, except for the fact that the tests in process_bug only look > at dontchange if it's a multiple bug change. Fine. Fake one that happens to only change one bug :-) Define the bug_id according to the multi-change method, and for everything else say &product=wibblefish&component=wibblefish&...&dontchange=wibblefish and they all won't change as long as the strings match :-) This way, you can also define multiple bug numbers and update multiple bugs at once with your comment, without needing more than one HTTP request. Save bandwidth :-) Gerv From kiko at async.com.br Fri Oct 25 21:06:07 2002 From: kiko at async.com.br (Christian Reis) Date: Fri, 25 Oct 2002 18:06:07 -0300 Subject: process_bug.cgi as backend and dontchange In-Reply-To: <3DB9AD8D.2070202@mozilla.org>; from gerv@mozilla.org on Fri, Oct 25, 2002 at 09:46:05PM +0100 References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB988B5.7030501@mozilla.org> <20021025165027.K5648@blackjesus.async.com.br> <3DAEF29F.8010006@mozilla.org> <3DB9AD8D.2070202@mozilla.org> Message-ID: <20021025180607.A23676@blackjesus.async.com.br> On Fri, Oct 25, 2002 at 09:46:05PM +0100, Gervase Markham wrote: > Christian Reis wrote: > > > So, I'm hacking away at this CVS->Bugzilla client. > > > > Context: it's a *pure* HTTP client - all it does is connect to > > process_bug.cgi, and send in a well-formed form that updates a single > > bug. If I want to add a comment to many bugs, I'll do multiple HTTP > > requests, no problem. > > > > Problem: there is no way to specify dontchange if you are changing a > > single bug. What I want is to add a single comment - and process_bug > > wants *all* the fields defined. dontchange would be a nice way to work > > around that, except for the fact that the tests in process_bug only look > > at dontchange if it's a multiple bug change. > > Fine. Fake one that happens to only change one bug :-) Define the bug_id This hack is better than one that defines a policy for process_bug.cgi of "if value == value of dontchange" ignore it? It would make things simpler to understand.. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From mbarnson at sisna.com Fri Oct 25 21:29:25 2002 From: mbarnson at sisna.com (Matthew P. Barnson) Date: 25 Oct 2002 15:29:25 -0600 Subject: [Fwd: updates (The Bugzilla Guide)] Message-ID: <1035581366.25683.29.camel@chandler.int.barnson.org> The Bugzilla Guide is updated at tldp.org, will be hitting the main site shortly and the mirrors over the next couple of days. BTW, the most recent version there was for 2.14, not 2.12; it's about 14 months old (August 2001). We should probably incorporate the following procedure into our release procedure, so tldp.org can be kept up-to-date (and subsequently keep the distribution creators up-to-date as well): * tar/gzip "mozilla/bugzilla/docs/sgml" directory. * mail to submit at en.tldp.org , including instructions on extraction, file locations, and which file to compile to create the master document (Bugzilla-Guide.sgml). -------------- next part -------------- An embedded message was scrubbed... From: "Greg Ferguson" Subject: updates (The Bugzilla Guide) Date: Fri, 25 Oct 2002 17:03:20 -0400 Size: 1425 URL: From jones at nceas.ucsb.edu Fri Oct 25 22:37:06 2002 From: jones at nceas.ucsb.edu (Matt Jones) Date: Fri, 25 Oct 2002 14:37:06 -0800 Subject: Comments for CVS -> Bugzilla Gateway part 2 References: <20021025114848.E5648@blackjesus.async.com.br> Message-ID: <3DB9C792.9020707@nceas.ucsb.edu> Christian, The cvszilla code uses "Bug: 34567" or "bug: 34567" How does your proposed code differ from the cvszilla code (http://homepages.kcbbs.gen.nz/~tonyg/)? I tried out cvszilla and it worked pretty well, but it imposed a "transaction" model on the process that we didn't want to use. But the underlying code for linking cvs log checking into bugzilla seems to be the core of what you're trying to implement. Maybe its a good starting place? Matt Christian Reis wrote: > I forgot; The bug I am working with is > http://bugzilla.mozilla.org/show_bug.cgi?id=129765 > > The second issue is: how do we allow specifying the bug # in the CVS > checkin comment? Timeless has suggested the formats > > "bug 23222" "bug #2323" "bug# 33432" > > I have seen > > "b=23232" and "b#=23232" on Mozilla bonsai. Anybody have any other > formats they think are likely? Should we support b=*? > > Take care, > -- > Christian Reis, Senior Engineer, Async Open Source, Brazil. > http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL > ---- > To view or change your list settings, click here: > -- ******************************************************************* Matt Jones jones at nceas dot ucsb dot edu http://www.nceas.ucsb.edu/ National Center for Ecological Analysis and Synthesis (NCEAS) Interested in ecological informatics? http://www.ecoinformatics.org ******************************************************************* From bbaetz at student.usyd.edu.au Sat Oct 26 00:50:29 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sat, 26 Oct 2002 10:50:29 +1000 (EST) Subject: process_bug.cgi as backend and dontchange In-Reply-To: <20021025165027.K5648@blackjesus.async.com.br> Message-ID: There usually is a reason for that sort of thing. I can't think what it is off the top of my head, but try a few rounds of |cvs annotate|. The other thing to be aware of is that there is no guarantee that the process_bug script format won't change - in fact, theres a rather large chance that it will, but by the time it does that you can use Bug.pm directly anyway. Bradley From bbaetz at student.usyd.edu.au Sat Oct 26 02:17:03 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sat, 26 Oct 2002 12:17:03 +1000 (EST) Subject: Bugzilla::CGI.pm checked in Message-ID: I've just checked in bug 147833, which makes us use CGI.pm for parsing queries/cookies/etc. I've kept backwards compat code with the following exceptions: - $::FILE is gone - this was the only place where the concept differed greatly from our stuff, and so it was easier to convert the single user (attachment.cgi) that to get working backwards compat code. Instead, use the CGI.pm API. See attachment.cgi for the changes. - Previously, data in $::COOKIE was left url_quoted. This has been fixed (because thats what CGI.pm's cookie method does, sensibly). I converted all the callers which cared (there was only 1, IIRC). Most users didn't unquote it anyway. (I'm wondering if this is somehow behind the bug where COLUMNLIST gets ignored every so often). This change doesn't apply to $::COOKIE{'Bugzilla_login'}, which the login code sets to a canonical value, and so it was always unquoted. ('bleh!' :) Ditto for the login cookie COOKIE. This is a massive mess, and will probably end up being sorted out when we move to User.pm objects. Other notes: - Using $::FORM, $::MFORM, or $::COOKIE is deprecated. Instead, at the top of the script, do |use vars qw($cgi);|, and then use $cgi->param or $cgi->cookie instead. (The reason for the |use vars| is that when we can eventually drop the backwards compat code, the only change will be to add |my $cgi = new Bugzilla::CGI()| to the top of each script, and we won't have to s/\$::cgi/\$cgi/ everywhere) - Note that using $cgi for header output should not yet be done. This is because CGI.pm will always add a content-type on text/* documents if we don't explicitly set one. This may have problems, and needs to be looked into a bit before its enabled. - There are no plans to use CGI.pm for output of html elements. My opinion is that TT is much more flexable for our purposes, and that it would be less confsuing if we don't mix the two, so its better off keeping it that way. I'm not too fixated on that, mind you. - I've set up CGI.pm to: a) not use xhtml (althogh this doesn't affect us, see the above item) b) use & instead of ; to separate url params, mainly for backwards compat Bradley From kiko at async.com.br Sat Oct 26 02:44:03 2002 From: kiko at async.com.br (Christian Reis) Date: Fri, 25 Oct 2002 23:44:03 -0300 Subject: process_bug.cgi as backend and dontchange In-Reply-To: ; from bbaetz@student.usyd.edu.au on Sat, Oct 26, 2002 at 10:50:29AM +1000 References: <20021025165027.K5648@blackjesus.async.com.br> Message-ID: <20021025234403.A23862@blackjesus.async.com.br> On Sat, Oct 26, 2002 at 10:50:29AM +1000, Bradley Baetz wrote: > The other thing to be aware of is that there is no guarantee that the > process_bug script format won't change - in fact, theres a rather large > chance that it will, but by the time it does that you can use Bug.pm > directly anyway. The problem isn't with the interface changing, but rather with it making what I need to do impossible. I'm using Gerv's suggestion to use id_XXX (simulating a mass change) and it works fine for now; hopefully, the same facility will be offered when process_bug changes by some HTTP (or XML-RPC, if that's where we will end up) interface script that can be used by software without access or permission to access the bugzilla database directly. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From bbaetz at student.usyd.edu.au Sat Oct 26 02:52:18 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sat, 26 Oct 2002 12:52:18 +1000 (EST) Subject: process_bug.cgi as backend and dontchange In-Reply-To: <20021025234403.A23862@blackjesus.async.com.br> Message-ID: On Fri, 25 Oct 2002, Christian Reis wrote: > The problem isn't with the interface changing, but rather with it making > what I need to do impossible. I'm using Gerv's suggestion to use id_XXX > (simulating a mass change) and it works fine for now; hopefully, the > same facility will be offered when process_bug changes by some HTTP (or > XML-RPC, if that's where we will end up) interface script that can be > used by software without access or permission to access the bugzilla > database directly. Well, eventually you'll do; my $bug = new Bugzilla::Bug($bug_id); $bug->add_comment("foo"); $bug->resolve("FIXED"); $bug->commit(); or something along those lines. Note the emphasis on 'eventually' :) Bradley From kiko at async.com.br Sat Oct 26 04:58:31 2002 From: kiko at async.com.br (Christian Reis) Date: Sat, 26 Oct 2002 01:58:31 -0300 Subject: process_bug.cgi as backend and dontchange In-Reply-To: ; from bbaetz@student.usyd.edu.au on Sat, Oct 26, 2002 at 12:52:18PM +1000 References: <20021025234403.A23862@blackjesus.async.com.br> Message-ID: <20021026015831.D23862@blackjesus.async.com.br> On Sat, Oct 26, 2002 at 12:52:18PM +1000, Bradley Baetz wrote: > Well, eventually you'll do; > > my $bug = new Bugzilla::Bug($bug_id); Not over HTTP, XML-RPC or anything remote like that, though :-P Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From bbaetz at student.usyd.edu.au Sat Oct 26 05:32:00 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sat, 26 Oct 2002 15:32:00 +1000 (EST) Subject: process_bug.cgi as backend and dontchange In-Reply-To: <20021026015831.D23862@blackjesus.async.com.br> Message-ID: On Sat, 26 Oct 2002, Christian Reis wrote: > On Sat, Oct 26, 2002 at 12:52:18PM +1000, Bradley Baetz wrote: > > Well, eventually you'll do; > > > > my $bug = new Bugzilla::Bug($bug_id); > > Not over HTTP, XML-RPC or anything remote like that, though :-P Well, why not? We could XML-RPCize Bug.pm, couldn't we? Or, more likely, have an XML-RPCable wrapper. Bradley From gerv at mozilla.org Sat Oct 26 07:59:48 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Oct 2002 08:59:48 +0100 Subject: process_bug.cgi as backend and dontchange In-Reply-To: <3DAEF29F.8010006@mozilla.org> References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB988B5.7030501@mozilla.org> <20021025165027.K5648@blackjesus.async.com.br> <3DAEF29F.8010006@mozilla.org> <3DB9AD8D.2070202@mozilla.org> <20021025180607.A23676@blackjesus.async.com.br> Message-ID: <3DBA4B74.5080507@mozilla.org> Christian Reis wrote: > This hack is better than one that defines a policy for process_bug.cgi > of "if value == value of dontchange" ignore it? It would make things > simpler to understand.. Your scheme is probably better; but it requires Bugzilla mods and so isn't compatible with older Bugzillas. I don't know if you care about that too much. Also, remember that the dontchange string could, however unlikely-ly, be set to the same name as a defined Product, because it's just localised text. Gerv From kiko at async.com.br Sat Oct 26 21:40:50 2002 From: kiko at async.com.br (Christian Reis) Date: Sat, 26 Oct 2002 18:40:50 -0300 Subject: process_bug.cgi as backend and dontchange In-Reply-To: <3DBA4B74.5080507@mozilla.org>; from gerv@mozilla.org on Sat, Oct 26, 2002 at 08:59:48AM +0100 References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB988B5.7030501@mozilla.org> <20021025165027.K5648@blackjesus.async.com.br> <3DAEF29F.8010006@mozilla.org> <3DB9AD8D.2070202@mozilla.org> <20021025180607.A23676@blackjesus.async.com.br> <3DAEF29F.8010006@mozilla.org> <3DBA4B74.5080507@mozilla.org> Message-ID: <20021026184050.G6401@blackjesus.async.com.br> On Sat, Oct 26, 2002 at 08:59:48AM +0100, Gervase Markham wrote: > > This hack is better than one that defines a policy for process_bug.cgi > > of "if value == value of dontchange" ignore it? It would make things > > simpler to understand.. > > Your scheme is probably better; but it requires Bugzilla mods and so > isn't compatible with older Bugzillas. I don't know if you care about > that too much. If you accept to review the patches (and justdave says they look okay), I'll open a bug for the change. I won't use it them in my script to allow backwards compatibility, but it will make process_bug semantics simpler and avoid other people being frustrated by it. > Also, remember that the dontchange string could, however unlikely-ly, be > set to the same name as a defined Product, because it's just localised text. Yes, but we have that problem with mass change today, too. The only solid way around it would be to have a dontchange form parameter that listed the names of the properties we didn't want to change (a bit reversed from the current situation), but that is only manageable through JS on a normal form, so it's not an option. We could also have a reserved word (something like we used to have with ---do_not_change--- that IIRC Bradley said we didn't want to localize, and with which I agree, unfortunately too late) that would be blocked when creating products. But all this is wish-wash now. :) Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From justdave at syndicomm.com Mon Oct 28 17:20:29 2002 From: justdave at syndicomm.com (David Miller) Date: Mon, 28 Oct 2002 12:20:29 -0500 Subject: UNCONFIRMED enabled for Bugzilla product Message-ID: The Bugzilla product on bugzilla.mozilla.org has now had the UNCONFIRMED status enabled. The volume of bugs we've been getting (not to mention the misfiles from people intending to file bugs against Mozilla itself, whose bugs are getting auto-confirmed when they shouldn't be because they misfiled) has been steadily increasing, and we need a better way to keep track of them. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Mon Oct 28 18:56:06 2002 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 28 Oct 2002 18:56:06 +0000 Subject: process_bug.cgi as backend and dontchange In-Reply-To: <20021026184050.G6401@blackjesus.async.com.br> References: <3DAEF29F.8010006@mozilla.org> <1035442649.1168.14.camel@megagerbil> <3DB988B5.7030501@mozilla.org> <20021025165027.K5648@blackjesus.async.com.br> <3DAEF29F.8010006@mozilla.org> <3DB9AD8D.2070202@mozilla.org> <20021025180607.A23676@blackjesus.async.com.br> <3DAEF29F.8010006@mozilla.org> <3DBA4B74.5080507@mozilla.org> <20021026184050.G6401@blackjesus.async.com.br> Message-ID: <3DBD8846.3030004@mozilla.org> Christian Reis wrote: > On Sat, Oct 26, 2002 at 08:59:48AM +0100, Gervase Markham wrote: > If you accept to review the patches (and justdave says they look okay), > I'll open a bug for the change. I won't use it them in my script to > allow backwards compatibility, but it will make process_bug semantics > simpler and avoid other people being frustrated by it. File the bug, attach the patches and I'll have a look :-) > We could also have a reserved word (something like we used to have with > ---do_not_change--- that IIRC Bradley said we didn't want to localize, > and with which I agree, unfortunately too late) that would be blocked > when creating products. But all this is wish-wash now. :) Why should this value not be localisable? It's perfectly possible to make it so, as I've demonstrated. Gerv From kiko at async.com.br Tue Oct 29 01:00:55 2002 From: kiko at async.com.br (Christian Reis) Date: Mon, 28 Oct 2002 22:00:55 -0300 Subject: process_bug.cgi as backend and dontchange In-Reply-To: <3DBD8846.3030004@mozilla.org>; from gerv@mozilla.org on Mon, Oct 28, 2002 at 06:56:06PM +0000 References: <3DB988B5.7030501@mozilla.org> <20021025165027.K5648@blackjesus.async.com.br> <3DAEF29F.8010006@mozilla.org> <3DB9AD8D.2070202@mozilla.org> <20021025180607.A23676@blackjesus.async.com.br> <3DAEF29F.8010006@mozilla.org> <3DBA4B74.5080507@mozilla.org> <20021026184050.G6401@blackjesus.async.com.br> <3DBD8846.3030004@mozilla.org> Message-ID: <20021028220055.M15049@blackjesus.async.com.br> On Mon, Oct 28, 2002 at 06:56:06PM +0000, Gervase Markham wrote: > Christian Reis wrote: > > On Sat, Oct 26, 2002 at 08:59:48AM +0100, Gervase Markham wrote: > > If you accept to review the patches (and justdave says they look okay), > > I'll open a bug for the change. I won't use it them in my script to > > allow backwards compatibility, but it will make process_bug semantics > > simpler and avoid other people being frustrated by it. > > File the bug, attach the patches and I'll have a look :-) http://bugzilla.mozilla.org/show_bug.cgi?id=177207 Justdave? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From gerv at mozilla.org Tue Oct 29 08:58:39 2002 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 29 Oct 2002 08:58:39 +0000 Subject: tbox is dead Message-ID: <3DBE4DBF.8030007@mozilla.org> Bradley Baetz wrote: > tbox is failing tests, because the perl mduels aren't installed. Doh! I completely forgot this. Apologies, everyone. > See my > comment. I have apatch which probley fixes this. Its tied up in the > mail::Sendmail bug, + I split it off somewhere else, and its mixed in > with > burnus' patch for localised template dirs. > > That patch makes us compil;e, but not process, the templates, We should probably install the modules rather than do this - because this patch removes some protections we have against people, er, checking in code without declaring module dependencies and stuff :-) Tinderbox owners: you need GD 1.20 or above, GD::Graph, and GD::Text::Align. If people want to disagree with me, then I'll extract bbaetz' patch. Gerv From bbaetz at student.usyd.edu.au Tue Oct 29 09:15:45 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Tue, 29 Oct 2002 20:15:45 +1100 (EST) Subject: tbox is dead Message-ID: Bah, wrong addr the first time On Tue, 29 Oct 2002, Gervase Markham wrote: > We should probably install the modules rather than do this - because > this patch removes some protections we have against people, er, checking > in code without declaring module dependencies and stuff :-) What tests aren't going to be run? This also breaks checksetup.pl, because we precompile _and_ prerun all templates, and those won't work. The bug I was referring to was bug 168191. The patch does a bit more than that, but it should be fairly clear whats going on. Bradley From myk at mozilla.org Tue Oct 29 20:44:29 2002 From: myk at mozilla.org (Myk Melez) Date: Tue, 29 Oct 2002 12:44:29 -0800 Subject: where to put CSS and JS files Message-ID: <3DBEF32D.2040907@mozilla.org> Gerv and I have been discussing where to put CSS and JS files over in bug 156548. http://bugzilla.mozilla.org/show_bug.cgi?id=156548 We'd like to put them in css/ and js/ subdirectories of the Bugzilla root directory. If you think that's a bad place for them, please comment in this forum or in the bug. -myk From caillon at returnzero.com Tue Oct 29 22:14:27 2002 From: caillon at returnzero.com (Christopher Aillon) Date: Tue, 29 Oct 2002 15:14:27 -0700 Subject: where to put CSS and JS files In-Reply-To: <3DBEF32D.2040907@mozilla.org> References: <3DBEF32D.2040907@mozilla.org> Message-ID: <3DBF0843.2000104@returnzero.com> Myk Melez wrote: > Gerv and I have been discussing where to put CSS and JS files over in > bug 156548. > > http://bugzilla.mozilla.org/show_bug.cgi?id=156548 > > We'd like to put them in css/ and js/ subdirectories of the Bugzilla > root directory. > > If you think that's a bad place for them, please comment in this forum > or in the bug. I think it is bad to pollute the top level directory with specific names such as css or js when there are other potential choices. Future Bugzilla versions may support VBScript, for example, and they may support XSLT. _Existing_ installs may wish to customize their install using VBScripts if they are a MS shop wanting to re-use some already existing vbs code for whatever reason, or if they are using xml templates and wish to style their pages with XSLT. So I think a better choice would be scripts/js/ and style/css/ > > > -myk > > > ---- > To view or change your list settings, click here: > > > From timeless at myrealbox.com Tue Oct 29 23:10:58 2002 From: timeless at myrealbox.com (timeless) Date: Tue, 29 Oct 2002 18:10:58 -0500 Subject: where to put CSS and JS files In-Reply-To: <3DBF0843.2000104@returnzero.com> References: <3DBEF32D.2040907@mozilla.org> <3DBF0843.2000104@returnzero.com> Message-ID: <3DBF1582.1050307@myrealbox.com> Myk Melez wrote: > Gerv and I have been discussing where to put CSS and JS files over in > bug 156548. > > http://bugzilla.mozilla.org/show_bug.cgi?id=156548 > > We'd like to put them in css/ and js/ subdirectories of the Bugzilla > root directory. > > If you think that's a bad place for them, please comment in this forum > or in the bug. Christopher Aillon wrote: > I think it is bad to pollute the top level directory with specific names > such as css or js when there are other potential choices. i agree > Future > Bugzilla versions may support VBScript, for example, and they may > support XSLT. _Existing_ installs may wish to customize their install > using VBScripts if they are a MS shop wanting to re-use some already > existing vbs code for whatever reason, or if they are using xml > templates and wish to style their pages with XSLT. So I think a better > choice would be scripts/js/ and style/css/ i wouldn't name a directory js or css scripts/ containing js+vbs+pls wouldn't hurt anyone. similarly a styles/ containing css+xslt+xslfo wouldn't hurt anyone. are there localization concerns? do the files relate to templates? are they truly global? From myk at mozilla.org Wed Oct 30 01:06:23 2002 From: myk at mozilla.org (Myk Melez) Date: Tue, 29 Oct 2002 17:06:23 -0800 Subject: where to put CSS and JS files In-Reply-To: <3DBEF32D.2040907@mozilla.org> References: <3DBEF32D.2040907@mozilla.org> <3DBF0843.2000104@returnzero.com> <3DBF1582.1050307@myrealbox.com> Message-ID: <3DBF308F.8050903@mozilla.org> timeless wrote: > Christopher Aillon wrote: > >> Bugzilla versions may support VBScript, for example, and they may >> support XSLT. _Existing_ installs may wish to customize their >> install using VBScripts if they are a MS shop wanting to re-use some >> already existing vbs code for whatever reason, or if they are using >> xml templates and wish to style their pages with XSLT. So I think a >> better choice would be scripts/js/ and style/css/ > > i wouldn't name a directory js or css > > scripts/ containing js+vbs+pls wouldn't hurt anyone. similarly a > styles/ containing css+xslt+xslfo wouldn't hurt anyone. I'm not a fan of preparing for possibilities that aren't even on the horizon (like your examples), but our other option was "style" and "logic" (more consistent than "scripts", and even more generic). Any problems with those names? > are there localization concerns? do the files relate to templates? are > they truly global? no, no, and yes -myk From bbaetz at student.usyd.edu.au Wed Oct 30 01:16:52 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Wed, 30 Oct 2002 12:16:52 +1100 (EST) Subject: where to put CSS and JS files In-Reply-To: <3DBF308F.8050903@mozilla.org> Message-ID: On Tue, 29 Oct 2002, Myk Melez wrote: > I'm not a fan of preparing for possibilities that aren't even on the > horizon (like your examples), but our other option was "style" and > "logic" (more consistent than "scripts", and even more generic). Any > problems with those names? I don't mind style, although I son't think we need style/js/ and style/xslt/ - just one directory should be fine. 'logic' sounds like a marketing buzzword :) 'scripts' or 'js' seem fine to me Bradley From jake at bugzilla.org Wed Oct 30 03:13:47 2002 From: jake at bugzilla.org (Jake) Date: Tue, 29 Oct 2002 22:13:47 -0500 Subject: where to put CSS and JS files In-Reply-To: References: Message-ID: <3DBF4E6B.7040004@bugzilla.org> Bradley Baetz wrote: >'logic' sounds like a marketing buzzword :) 'scripts' or 'js' seem fine to >me > > I agree with Bradly on this... it's pretty much the first thing I thought when I saw 'logic'... but 'scripts' is reasonable. 'js' isn't bad either as I really doubt that we'll intentionally include any vbscript :) So would we just move what's currently in css/ to styles/? From gerv at mozilla.org Wed Oct 30 08:28:48 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Oct 2002 08:28:48 +0000 Subject: where to put CSS and JS files In-Reply-To: <3DBEF32D.2040907@mozilla.org> References: <3DBEF32D.2040907@mozilla.org> <3DBF0843.2000104@returnzero.com> Message-ID: <3DBF9840.5080901@mozilla.org> Christopher Aillon wrote: > Myk Melez wrote: > > I think it is bad to pollute the top level directory with specific names > such as css or js when there are other potential choices. Future > Bugzilla versions may support VBScript, for example, and they may > support XSLT. The day Bugzilla starts using VBScript is the day I stop working on it :-) And as I said in the relevant bug, when everyone's browser supports XSLT, in about seven years, we can probably cope with creating another top-level directory. Another point is that we already have a css directory, and removing them from CVS is a hassle, and it'll be confusing if people see it there and it's empty. Pragmatic, but true. css and js are fine, IMO. Gerv From bugreport at peshkin.net Wed Oct 30 14:49:57 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 30 Oct 2002 06:49:57 -0800 Subject: upgrading b.m.o; developer's release References: <3DB869FF.8090707@mozilla.org> Message-ID: <3DBFF195.4010805@peshkin.net> Myk Melez wrote: > > > How about generating a short list of things we want in for the > developer's release and then freezing the trunk to all except those > fixes for about a week before the upgrade (i.e. by Friday, November > 1)? Ideally we'd have everything in before that date so we have a week > to test the trunk before it goes into production on b.m.o. > > Also ideally we'd release the developer's release a few days before > b.m.o upgrades so other installations have a chance to shake out some > of the regressions first. > Myk, So you are pulling the release that goes to BMO sometime between Nov 1 and Nov 8, correct? Why not pull a controlled branch just like any other stable release on Nov 1 and have any changes to the tip applied to both ONLY if needed for BMO? -Joel From caillon at returnzero.com Wed Oct 30 18:04:46 2002 From: caillon at returnzero.com (Christopher Aillon) Date: Wed, 30 Oct 2002 11:04:46 -0700 Subject: where to put CSS and JS files In-Reply-To: <3DBF9840.5080901@mozilla.org> References: <3DBEF32D.2040907@mozilla.org> <3DBF0843.2000104@returnzero.com> <3DBF9840.5080901@mozilla.org> Message-ID: <3DC01F3E.5070705@returnzero.com> Gervase Markham wrote: > The day Bugzilla starts using VBScript is the day I stop working on it :-) If Mozilla supports it, will you stop using it as a browser? Because it very likely will someday.... Also note that VBScript itself is not evil. It is the fact that IE's implementation blindly executes anything and everything. They have had just as serious security bugs with executing JS, but nobody complains about JS being evil.... > And as I said in the relevant bug, when everyone's browser supports > XSLT, in about seven years, Web usage history has shown that everyone's browser will never support this. There will be new browser projects that are in early development and don't support it, or people will be using legacy software that hasn't yet supported it. That said, 90-something percent of browsers out there support it. Today. Microsoft IE has had XSLT support for longer than Mozilla has IIRC. And Mozilla has had it for quite a while.... Also, you are forgetting that we support templates. Just because you in particular never want to see VBScript support does not mean that tomorrow, some MS guy will download Bugzilla to deploy it, but be required by MS law to use some VBScript fu. Or that some W3C member will want to use it to track bugs in their XSLT test suite, and they want to use XSLT. Anyway, I just used VBScript and XSLT as examples. There are other scripting and style languages, though VBScript and XSLT are the most prevalent alternatives on the web, both which happen to be supported on over 90% of browsers that people are using Today. > we can probably cope with creating another top-level directory. > > Another point is that we already have a css directory, and removing > them from CVS is a hassle, and it'll be confusing if people see it > there and it's empty. Pragmatic, but true. It's a hassle yes. But it's not impossible. It will not only be confusing to users but show poor judgement on the developer who leaves a needless empty directory without removing it. It's not like we cvs remove directories every day.... surely we can do it just once... Also, I see a count of 4 people who appear to be in favor of styles/ and scripts/ and only 2 who are in favor of leaving css/ and js/. Why are we jumping so quickly to create js/ (judging from the bug)? From myk at mozilla.org Wed Oct 30 18:28:04 2002 From: myk at mozilla.org (Myk Melez) Date: Wed, 30 Oct 2002 10:28:04 -0800 Subject: upgrading b.m.o; developer's release In-Reply-To: <3DB869FF.8090707@mozilla.org> References: <3DB869FF.8090707@mozilla.org> <3DBFF195.4010805@peshkin.net> Message-ID: <3DC024B4.40400@mozilla.org> Joel Peshkin wrote: > So you are pulling the release that goes to BMO sometime between > Nov 1 and Nov 8, correct? Why not pull a controlled branch just like > any other stable release on Nov 1 and have any changes to the tip > applied to both ONLY if needed for BMO? Well, primarily because I've never done it before, :-) but also because I want to stay close to the tip, and I think it's reasonable for the tip to freeze for stability, especially if we do a developers release at the same time. (Of course, if the release took too long, a branch would start making more sense.) -myk From myk at mozilla.org Wed Oct 30 18:42:11 2002 From: myk at mozilla.org (Myk Melez) Date: Wed, 30 Oct 2002 10:42:11 -0800 Subject: where to put CSS and JS files In-Reply-To: <3DBEF32D.2040907@mozilla.org> References: <3DBEF32D.2040907@mozilla.org> <3DBF0843.2000104@returnzero.com> <3DBF9840.5080901@mozilla.org> <3DC01F3E.5070705@returnzero.com> Message-ID: <3DC02803.6050005@mozilla.org> Christopher Aillon wrote: > Gervase Markham wrote: > >> The day Bugzilla starts using VBScript is the day I stop working on >> it :-) > > > If Mozilla supports it, will you stop using it as a browser? Oh god, this is exactly the direction of discussion that makes me oppose running major changes by the developers list. Dave, here are the three extant alternatives. All of them are good enough (TM). Pick one and let's move on, please, or tell me I can check one JS file into the top-level directory until the argument is over, after which I'll move it to the appropriate directory (moving files being so much easier than moving directories). css/ and js/ - short, obvious, and css/ already exists; less flexible than the other alternatives because it specifies the type of files it will contain (although all examples of the problem this causes are hypothetical). style/ and logic/ - logically consistent, but leaves css/ empty, and people think "logic" is bad because marketingesque. style/ and scripts/ - the popular choice, but leaves css/ empty and logically inconsistent. > It's a hassle yes. But it's not impossible. It will not only be > confusing to users but show poor judgement on the developer who leaves > a needless empty directory without removing it. It's not like we cvs > remove directories every day.... surely we can do it just once... Technical note: not really. There's no such thing as "cvs remove directory", there's only "manually delete directory from CVS repository, causing chaos in local working copies". We don't want to go there. -myk From tara at tequilarista.org Wed Oct 30 19:31:12 2002 From: tara at tequilarista.org (Tara Hernandez) Date: Wed, 30 Oct 2002 11:31:12 -0800 Subject: where to put CSS and JS files References: <3DBEF32D.2040907@mozilla.org> <3DBF0843.2000104@returnzero.com> <3DBF9840.5080901@mozilla.org> <3DC01F3E.5070705@returnzero.com> <3DC02803.6050005@mozilla.org> Message-ID: <3DC03380.40406@tequilarista.org> Just to point out, cvs up -P will get rid of any empty directories, and cvs co ignores them by default. Myk Melez wrote: > Christopher Aillon wrote: > >> Gervase Markham wrote: >> >>> The day Bugzilla starts using VBScript is the day I stop working on >>> it :-) >> >> >> >> If Mozilla supports it, will you stop using it as a browser? > > > Oh god, this is exactly the direction of discussion that makes me > oppose running major changes by the developers list. > > Dave, here are the three extant alternatives. All of them are good > enough (TM). Pick one and let's move on, please, or tell me I can > check one JS file into the top-level directory until the argument is > over, after which I'll move it to the appropriate directory (moving > files being so much easier than moving directories). > > css/ and js/ - short, obvious, and css/ already exists; less flexible > than the other alternatives because it specifies the type of files it > will contain (although all examples of the problem this causes are > hypothetical). > > style/ and logic/ - logically consistent, but leaves css/ empty, and > people think "logic" is bad because marketingesque. > > style/ and scripts/ - the popular choice, but leaves css/ empty and > logically inconsistent. > >> It's a hassle yes. But it's not impossible. It will not only be >> confusing to users but show poor judgement on the developer who >> leaves a needless empty directory without removing it. It's not like >> we cvs remove directories every day.... surely we can do it just >> once... > > > Technical note: not really. There's no such thing as "cvs remove > directory", there's only "manually delete directory from CVS > repository, causing chaos in local working copies". We don't want to > go there. > > -myk > > > ---- > To view or change your list settings, click here: > > > From justdave at syndicomm.com Wed Oct 30 19:49:30 2002 From: justdave at syndicomm.com (David Miller) Date: Wed, 30 Oct 2002 14:49:30 -0500 Subject: where to put CSS and JS files In-Reply-To: <3DC03380.40406@tequilarista.org> References: <3DBEF32D.2040907@mozilla.org> <3DBF0843.2000104@returnzero.com> <3DBF9840.5080901@mozilla.org> <3DC01F3E.5070705@returnzero.com> <3DC02803.6050005@mozilla.org> <3DC03380.40406@tequilarista.org> Message-ID: On 10/30/02 11:31 AM -0800, Tara Hernandez wrote: > Just to point out, cvs up -P will get rid of any empty directories, and > cvs co ignores them by default. cvs co does not ignore them by default. At least not with cvs 1.11.2. I had to have my maketarball script do a cvs up -P on the resulting checkout prior to tarballing it to get rid of the empty directories. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at syndicomm.com Wed Oct 30 20:20:19 2002 From: justdave at syndicomm.com (David Miller) Date: Wed, 30 Oct 2002 15:20:19 -0500 Subject: where to put CSS and JS files In-Reply-To: <3DC02803.6050005@mozilla.org> References: <3DBEF32D.2040907@mozilla.org> <3DBF0843.2000104@returnzero.com> <3DBF9840.5080901@mozilla.org> <3DC01F3E.5070705@returnzero.com> <3DC02803.6050005@mozilla.org> Message-ID: On 10/30/02 10:42 AM -0800, Myk Melez wrote: > Dave, here are the three extant alternatives. All of them are good > enough (TM). Pick one and let's move on > css/ and js/ - short, obvious, and css/ already exists; less flexible > than the other alternatives because it specifies the type of files it > will contain (although all examples of the problem this causes are > hypothetical). And we can always add more directories later for other types if we want to stay consistent. I'm pretty sure when the "Makefile" thing lands (if it ever does) our entire directory structure is going to get changed around anyway. > style/ and logic/ - logically consistent, but leaves css/ empty, and > people think "logic" is bad because marketingesque. > > style/ and scripts/ - the popular choice, but leaves css/ empty and > logically inconsistent. I don't like scripts, because guess what a CGI is? :-) I'm not sure logic works for me either. Personally I'd just go with css/ and js/ since they're specific to what we're using. If someone adds VBScript files later, they can always add a vbs/ directory or something. >> It's a hassle yes. But it's not impossible. It will not only be >> confusing to users but show poor judgement on the developer who leaves >> a needless empty directory without removing it. It's not like we cvs >> remove directories every day.... surely we can do it just once... > > Technical note: not really. There's no such thing as "cvs remove > directory", there's only "manually delete directory from CVS repository, > causing chaos in local working copies". We don't want to go there. We've done this exactly once that I know of in the past, to remove some directories that were created on accident. Anyone who had a cvs checkout updated within the three weeks those directories existed had to manually remove them from their CVS/Entries files in order to get cvs update to not error out. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/