From gerv at mozilla.org Sun Sep 1 22:26:14 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 01 Sep 2002 23:26:14 +0100 Subject: Who uses data/sqllog? References: Message-ID: <3D729406.3060203@mozilla.org> Bradley Baetz wrote: > On Sat, 31 Aug 2002, Bradley Baetz wrote: > >>Emulating data/sqllog exactly is going to be a big pain. > > ... actually, while it is a pain, I have to do it anyway to support our > shadowdb stuff. So I'm still curious about the answers, but its going to > stay anyway, at least for the time being. Can't we remove the shadowdb now? Or are we not yet at a stage where that's practical? It seems a waste to write this emulation code so it can appear in a few developer releases and then get thrown away. Gerv From gerv at mozilla.org Sun Sep 1 22:28:24 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 01 Sep 2002 23:28:24 +0100 Subject: Exception modules? References: Message-ID: <3D729488.2010205@mozilla.org> Bradley Baetz wrote: > Anyone know a good exception-style module for perl, which we can use in > bugzilla? > > As more stuff moves to modules which may be resued from non-CGI scripts, > we really should have a way of reporting errors apart from using die. Can't we redefine the *Error functions in non-CGI scripts to do something appropriate? Gerv From bbaetz at student.usyd.edu.au Mon Sep 2 00:31:40 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Mon, 2 Sep 2002 10:31:40 +1000 (EST) Subject: Who uses data/sqllog? In-Reply-To: <3D729406.3060203@mozilla.org> Message-ID: On Sun, 1 Sep 2002, Gervase Markham wrote: > Bradley Baetz wrote: > > On Sat, 31 Aug 2002, Bradley Baetz wrote: > > > >>Emulating data/sqllog exactly is going to be a big pain. > > > > ... actually, while it is a pain, I have to do it anyway to support our > > shadowdb stuff. So I'm still curious about the answers, but its going to > > stay anyway, at least for the time being. > > Can't we remove the shadowdb now? Or are we not yet at a stage where > that's practical? Well.... The replacement isn't there.Plus, the DBI author is on holiday, so my patch to make DBI only check input values for taintedness hasn't been accepted. > > It seems a waste to write this emulation code so it can appear in a few > developer releases and then get thrown away. > My design allows the replication stuff to basically be a dropin replacement, only touching Bugzilla/DBI.pm > Gerv > Bradley From bbaetz at student.usyd.edu.au Mon Sep 2 00:34:29 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Mon, 2 Sep 2002 10:34:29 +1000 (EST) Subject: Exception modules? In-Reply-To: <3D729488.2010205@mozilla.org> Message-ID: On Sun, 1 Sep 2002, Gervase Markham wrote: > Bradley Baetz wrote: > > Anyone know a good exception-style module for perl, which we can use in > > bugzilla? > > > > As more stuff moves to modules which may be resued from non-CGI scripts, > > we really should have a way of reporting errors apart from using die. > > Can't we redefine the *Error functions in non-CGI scripts to do > something appropriate? Not really... Note that some of the stuf is wrong. For example, if the mail temptlaes fail, we don't really want to stop in the middle with throwtemplateerror (like we currently do), we want to keep going. Exceptions are 'nicer' that way, in that we can catch template errors, while letting DB errors lead to a script exit. Bradley From bbaetz at student.usyd.edu.au Tue Sep 3 01:29:02 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Tue, 3 Sep 2002 11:29:02 +1000 (EST) Subject: More DBI stuff Message-ID: There are a couple of problems with the DBI stuff. a) Theres no generic pre/post hook. This means that: - modifications cna't be done using placeholders, because we don't then have the right data for the shadowlog - sqllog won't log placeholders. The DBI wasn't really meant for doing this at the level we are, and since we plan on moving to replication (which I will do RSN) this will cease to be a problem. So I think I will remove our sqllog functionality, in favour of DBI's trace stuff. b) taint checking is probably going to change: Placeholders also have an advantage wrt taint checking. Currently, we sqlquote all strings, which detaints them. Using placeholders, we pass the unquoted version in, and let DBI handle quoting. _However_, this means that the actual values must be detainted. I consider this to be a good thing, since we really should be doing length-style checks on stuff before inserting, and the few places like get_product_id which we have to validate input can just always trick_taint. If we have the rule that $vars don't appear in sql statements, ever, then there isn't a risk of inserting a string which has been trick_tainted, but not sqlquoted. (For this, we also need my patches to DBI, which will probably be accepted when the author gets back from vacation next week) There is no speed penalty with placeholders which I can measure; trying 10000 times with the Benchmark module showed each one in front a roughly equal % of the time. I suspect that the overhead of scanning a string for ? characters in C is minimal. I had converted attachment.cgi over to the new scheme (as an example), although myk has rewritten that. Oh well.... Anyway, my plan is now: - Make Bugzilla::DBI work - Add support for replication - Drop shadowdb support - Convert existing cgi's over to the DBI syntax myk: There will be a short transition period, but I'd prefer to kill the shadowdb before 2.18. You mentioned that bmo was going to be updated after request tracker went in; if I get replication support working by then, would you be willing to move to that at some point before the update after that (so that I could remove support right after the update) Bradley From aludlow at lionhead.com Tue Sep 3 11:14:23 2002 From: aludlow at lionhead.com (Aaron Ludlow) Date: Tue, 3 Sep 2002 12:14:23 +0100 Subject: owner of a component Message-ID: <001801c2533b$0ed19fb0$4d0fa8c0@lhdomain.lionhead.com> Hi gang, Hope this works, newbie here:-). Quick question, if I am an owner of a database, and I set myself up as the owner of one of the components, when I enter a bug I do not receive the email, even if I Cc myself on it. It says email sent to no one, excluding then my email. Any ideas? Thanks, --- Aaron Ludlow Lionhead Studios Gameplay & Testing Tel: 01483 401 053 Email: aludlow at lionhead.com Web: www.Lionhead.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From preed at sigkill.com Tue Sep 3 12:47:44 2002 From: preed at sigkill.com (J. Paul Reed) Date: Tue, 3 Sep 2002 05:47:44 -0700 (PDT) Subject: owner of a component In-Reply-To: <001801c2533b$0ed19fb0$4d0fa8c0@lhdomain.lionhead.com> Message-ID: On Tue, 3 Sep 2002, Aaron Ludlow wrote: > Hope this works, newbie here:-). Quick question, if I am an owner of a > database, and I set myself up as the owner of one of the components, when > I enter a bug I do not receive the email, even if I Cc myself on it. It > says email sent to no one, excluding then my email. This is an attempt to reduce the amount of mail you get. If you make a change on the bug, the thinking is you don't need to be notified that you made the change; you know you made the change because... you made the change. ;-) So, the logged-in user making any changes or adding comments will never get email; only other people on the Cc-list, the reporter, and the owner (assuming their personal account settings don't preclude mail being sent to them, which is another reason mail could be sent to "no one.") Incidentally, this type of question should probably go to the newsgroup. 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 justdave at syndicomm.com Tue Sep 3 12:31:46 2002 From: justdave at syndicomm.com (David Miller) Date: Tue, 3 Sep 2002 08:31:46 -0400 Subject: owner of a component In-Reply-To: References: Message-ID: On 9/3/02 5:47 AM -0700, J. Paul Reed wrote: > On Tue, 3 Sep 2002, Aaron Ludlow wrote: > >> Hope this works, newbie here:-). Quick question, if I am an owner of a >> database, and I set myself up as the owner of one of the components, when >> I enter a bug I do not receive the email, even if I Cc myself on it. It >> says email sent to no one, excluding then my email. > So, the logged-in user making any changes or adding comments will never get > email; only other people on the Cc-list, the reporter, and the owner > (assuming their personal account settings don't preclude mail being sent to > them, which is another reason mail could be sent to "no one.") Actually, that's a preference, too, you can set it to always send you mail. But the above is the default. > Incidentally, this type of question should probably go to the newsgroup. Yep. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From kniht at us.ibm.com Tue Sep 3 14:48:23 2002 From: kniht at us.ibm.com (Jon Tollefson) Date: 03 Sep 2002 09:48:23 -0500 Subject: Who uses data/sqllog? In-Reply-To: References: Message-ID: <1031064503.4460.5.camel@cyberdyne.rchland.ibm.com> I use it for occasional debugging. Its nice sometimes to have something to trace what sql statements are being issued. The DBI trace information, though more verbose, looks like it would be ok. Jon On Sat, 2002-08-31 at 04:28, Bradley Baetz wrote: > Emulating data/sqllog exactly is going to be a big pain. So, I'd like to > know who actually uses it, and if they do, what for? > ... > So, the choices are: > > 1) If people only use this for occasional debugging, then I'll just set > DBI up to trace to data/sqllog if it exists. > > 2) I can keep the current implementation basically as-is > > 3) Something else. > > Thoughts? > > Bradley From jacob.steenhagen at us.army.mil Tue Sep 3 15:56:49 2002 From: jacob.steenhagen at us.army.mil (PFC Steenhagen, Jacob) Date: Tue, 03 Sep 2002 11:56:49 -0400 Subject: Exception modules? References: Message-ID: <3D74DBC1.5060608@us.army.mil> Bradley Baetz wrote: >Anyone know a good exception-style module for perl, which we can use in >bugzilla? > >As more stuff moves to modules which may be resued from non-CGI scripts, >we really should have a way of reporting errors apart from using die. > >There are a few on CPAN, none of which look like they've been updated in a >while, though. > >(Error.pm, Exception.pm are the main ones) > > Perhaps we should write our own Bugzilla::Error module. I think that would provide us the ability to better respond to error messages a pre-packaged system as I doubt there are any pre-packaged systems designed to handle CGI, e-mail, and the Template Toolkit, and our i18n scheme (along w/whatever else we throw out there). > > From bbaetz at student.usyd.edu.au Tue Sep 3 23:24:54 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Wed, 4 Sep 2002 09:24:54 +1000 (EST) Subject: Exception modules? In-Reply-To: <3D74DBC1.5060608@us.army.mil> Message-ID: On Tue, 3 Sep 2002, PFC Steenhagen, Jacob wrote: > Perhaps we should write our own Bugzilla::Error module. I'd like to avoid that; I'm looking for a framswork, not a full solution. all the packages I suggested allow arbitrary exception types to be created, with arbitrary strings (In our case, probably the error code for displayerror + friends) Bradley From myk at mozilla.org Wed Sep 4 17:58:13 2002 From: myk at mozilla.org (Myk Melez) Date: Wed, 04 Sep 2002 10:58:13 -0700 Subject: Who uses data/sqllog? References: Message-ID: <3D7649B5.1000702@mozilla.org> Bradley Baetz wrote: >Emulating data/sqllog exactly is going to be a big pain. So, I'd like to >know who actually uses it, and if they do, what for? > > I used it once or twice on b.m.o, but now I use the MySQL long query log and the output of mysqld-watcher.pl. -myk From gerv at mozilla.org Wed Sep 4 20:48:27 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 04 Sep 2002 21:48:27 +0100 Subject: Website directory structure References: <3D615BD6.3050302@mozilla.org> Message-ID: <3D76719B.5030805@mozilla.org> > Matty and I have been thinking along these lines, too. Here's the list > Matty sent me not too long back in IRC... I want to check in the Localisers Guide ASAP. So, after the conversation above, I plan to create two top-level directories - currently, I think they should be called "administrators" and "developers", but I can see some people might want to argue for shorter names such as "admin" and "dev" or "hacking", even. Speak quickly, or forever hold your peace. Gerv From bugreport at peshkin.net Wed Sep 4 21:15:14 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 04 Sep 2002 14:15:14 -0700 Subject: Website directory structure References: <3D615BD6.3050302@mozilla.org> <3D76719B.5030805@mozilla.org> Message-ID: <3D7677E2.1010809@peshkin.net> Gervase Markham wrote: > > > I want to check in the Localisers Guide ASAP. So, after the > conversation above, I plan to create two top-level directories - > currently, I think they should be called "administrators" and > "developers", but I can see some people might want to argue for > shorter names such as "admin" and "dev" or "hacking", even. > > Speak quickly, or forever hold your peace. > > Gerv Gerv, We should keep room in the scheme of things for a testing guide as well. This would have information on how to reinit, reload, copy, and rollback databases as well as how to use non-interactive test techniques. -Joel From preed at sigkill.com Thu Sep 5 05:17:34 2002 From: preed at sigkill.com (J. Paul Reed) Date: Wed, 4 Sep 2002 22:17:34 -0700 (PDT) Subject: Website directory structure In-Reply-To: <3D76719B.5030805@mozilla.org> Message-ID: On Wed, 4 Sep 2002, Gervase Markham wrote: > Speak quickly, or forever hold your peace. I like short names, ala 'admin', 'dev', and 'test'. But *really*, it doesn't matter. 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 bugreport at peshkin.net Fri Sep 6 03:27:18 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 05 Sep 2002 20:27:18 -0700 Subject: Group system benchmarks Message-ID: <3D782096.3080504@peshkin.net> Benchmarks on current schema in the Groups_20020716_Branch.... AMD Duron 950 system hosting both BZ and mysqld 10000 users 500 open groups, 500 closed groups (i.e. almost all users are members of 500 of the 1000 defined groups) Rederivation of group membership happens on the first login by each user after a group definition change has occurred, rederive 1.3 sec wall time each user for membership in 500 groups (60% cpu=perl, 40% cpu=sql) With only 50 groups this falls to 0.13 sec each fetching all bugs and then calling CanSeeBug on each..... 500 bugs retrieved by search but only 3 visible --> 2 seconds elapsed wall time 50000 bugs retrieved by search but only 3 visible --> 140 seconds elapsed wall time Building a join to bug_group_map into the query..... 50000 bugs retrieved by search but only 3 visible --> 10 seconds elapsed wall time Size of user_group_map for 116 users in 500 groups each = 1.2MB I think this is scalable enough based on this. If anyone can provide some numbers from large BZ sites to plug into this analysis, please post them. -Joel From bbaetz at student.usyd.edu.au Fri Sep 6 04:04:00 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Fri, 6 Sep 2002 14:04:00 +1000 (EST) Subject: DBI and the shadowdb Message-ID: So, after playing with this for a while, ISTM that almost all of the benefits we get by using DBI methods won't actually work with the shadowdb. Instead, I'm going to work on making the shadowdb work with replication and then remove support for the current stuff. I would _REALLY_ like to remove the current shadow stuff before 2.18. Since only bmo uses it, that puts it down to myk. myk, if I produced a replication patch which allowed teh existing shadowdb to be used in parallel, would bmo use it when it upgrades to get request tracker soonish? And would you object if I then removed the fallback support for syncshadowdb soon after? Does anyone else have an opinion about this? Bradley From myk at mozilla.org Fri Sep 6 08:50:03 2002 From: myk at mozilla.org (Myk Melez) Date: Fri, 06 Sep 2002 01:50:03 -0700 Subject: DBI and the shadowdb References: Message-ID: <3D786C3B.4020503@mozilla.org> Bradley Baetz wrote: >myk, if I produced a replication patch which allowed teh existing >shadowdb to be used in parallel, would bmo use it when it upgrades to get >request tracker soonish? And would you object if I then removed the >fallback support for syncshadowdb soon after? > I'm curious what you mean by "in parallel", and doing this gives me some work to do as well (reconfiguring the server) that I'm not sure I'll have time for before the upgrade, but if I do, and if the replication patch went in and looked very good, I would turn it on after upgrade regressions were dealt with, and if it worked I wouldn't have any problem with removing the shadow database code. As far as I am concerned, good riddance to the shadowdb. Even if I don't get the server reconfigured before the upgrade, though, it's something I can (and will) do afterwards, so working on the replication patch isn't a waste of time no matter when I get to the reconfiguration. Btw- Are there any plans to make it possible to install a read-only installation of Bugzilla that directs all write requests to another installation. This, along with replication, would provide an quick and easy scalability solution (just add more boxes). -myk From bugreport at peshkin.net Fri Sep 6 14:22:33 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 06 Sep 2002 07:22:33 -0700 Subject: More Benchmarks Message-ID: <3D78BA29.10400@peshkin.net> At bbaetz's request, I reran one of these with the code hacked to use $::db->prepare("SELECT stuff WHERE field = ?") outside the critical loops and $sth->execute($value) inside instead of using SendSQL. Doing this only on a the inner loop of the 500 group rederivation (one prepare, and 500 executes), this sped up the function by a nearly factor of 2 from 1.3sec to 0.7sec Bring on Bugzilla::DBI -Joel Joel Peshkin wrote: > > Benchmarks on current schema in the Groups_20020716_Branch.... > > AMD Duron 950 system hosting both BZ and mysqld > > 10000 users 500 open groups, 500 closed groups (i.e. almost all > users are members of 500 > of the 1000 defined groups) > > Rederivation of group membership happens on the first login by each > user after a group definition change has occurred, > > rederive 1.3 sec wall time each user for membership in 500 groups (60% > cpu=perl, 40% cpu=sql) > With only 50 groups this falls to 0.13 sec each > > fetching all bugs and then calling CanSeeBug on each..... > 500 bugs retrieved by search but only 3 visible --> 2 seconds elapsed > wall time > 50000 bugs retrieved by search but only 3 visible --> 140 seconds > elapsed wall time > > Building a join to bug_group_map into the query..... > 50000 bugs retrieved by search but only 3 visible --> 10 seconds > elapsed wall time > > Size of user_group_map for 116 users in 500 groups each = 1.2MB > > I think this is scalable enough based on this. If anyone can provide > some numbers from large BZ sites to plug into this analysis, please > post them. > > -Joel > From bugreport at peshkin.net Fri Sep 6 19:04:15 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 06 Sep 2002 12:04:15 -0700 Subject: Has anyone looked at using the byte-complier? Message-ID: <3D78FC2F.6090809@peshkin.net> Interesting point was raised on the Newsgroup today. Has anyone looked at using the byte-compiler to speed up BZ loading? http://www.perldoc.com/perl5.8.0/pod/perlcompile.html From justdave at syndicomm.com Fri Sep 6 23:38:04 2002 From: justdave at syndicomm.com (David Miller) Date: Fri, 6 Sep 2002 19:38:04 -0400 Subject: Has anyone looked at using the byte-complier? In-Reply-To: <3D78FC2F.6090809@peshkin.net> References: <3D78FC2F.6090809@peshkin.net> Message-ID: On 9/6/02 12:04 PM -0700, Joel Peshkin wrote: > Interesting point was raised on the Newsgroup today. Has anyone looked > at using the byte-compiler to speed up BZ loading? > > http://www.perldoc.com/perl5.8.0/pod/perlcompile.html Yeah, I doubt if it works on anything prior to perl 5.8.0. I tried messing with it once in 5.6.1 and never got it working. The docs all but said "this probably doesn't work for everything yet" at the time. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From matty at chariot.net.au Sat Sep 7 04:41:07 2002 From: matty at chariot.net.au (MattyT) Date: 07 Sep 2002 14:11:07 +0930 Subject: Has anyone looked at using the byte-complier? In-Reply-To: References: <3D78FC2F.6090809@peshkin.net> Message-ID: <1031373668.2997.2.camel@megagerbil> On Sat, 2002-09-07 at 09:08, David Miller wrote: > Yeah, I doubt if it works on anything prior to perl 5.8.0. I tried messing > with it once in 5.6.1 and never got it working. The docs all but said > "this probably doesn't work for everything yet" at the time. It might be worth thinking about though. If it does work reliably, then AFAICS we wouldn't really need mod_perl. Granted, a lot of Bugzilla variables won't get cached, but I believe DBI does its own caching anyway. If we can avoid hacking the code to work with mod_perl, it's probably worthwhile. -- 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 Sun Sep 8 08:24:47 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sun, 8 Sep 2002 18:24:47 +1000 (EST) Subject: DBI and the shadowdb In-Reply-To: <3D786C3B.4020503@mozilla.org> Message-ID: On Fri, 6 Sep 2002, Myk Melez wrote: > Bradley Baetz wrote: > > >myk, if I produced a replication patch which allowed teh existing > >shadowdb to be used in parallel, would bmo use it when it upgrades to get > >request tracker soonish? And would you object if I then removed the > >fallback support for syncshadowdb soon after? > > > I'm curious what you mean by "in parallel", and doing this gives me some > work to do as well (reconfiguring the server) that I'm not sure I'll > have time for before the upgrade, but if I do, and if the replication > patch went in and looked very good, I would turn it on after upgrade > regressions were dealt with, and if it worked I wouldn't have any > problem with removing the shadow database code. As far as I am > concerned, good riddance to the shadowdb. 'In parallel' == The ability to run with either synshadowdb or replication. This code is going to be _ugly_. Without the 'in parallel' stuff, you'd ahve to set up replication before the update. > > Even if I don't get the server reconfigured before the upgrade, though, > it's something I can (and will) do afterwards, so working on the > replication patch isn't a waste of time no matter when I get to the > reconfiguration. OK. I'll update my current patch, and see where that leaves us. > > Btw- Are there any plans to make it possible to install a read-only > installation of Bugzilla that directs all write requests to another > installation. This, along with replication, would provide an quick and > easy scalability solution (just add more boxes). > Well, we could use DBD::multiplex. The problem is the definition of 'write request', esp with consistent data, and so on. > -myk > Bradley From bbaetz at student.usyd.edu.au Sun Sep 8 08:25:18 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sun, 8 Sep 2002 18:25:18 +1000 (EST) Subject: Has anyone looked at using the byte-complier? In-Reply-To: <3D78FC2F.6090809@peshkin.net> Message-ID: Lets use mod_perl before we worry about 'experimental' perl features like that.. Bradley From preed at sigkill.com Sun Sep 8 18:34:38 2002 From: preed at sigkill.com (J. Paul Reed) Date: Sun, 8 Sep 2002 11:34:38 -0700 (PDT) Subject: Has anyone looked at using the byte-complier? In-Reply-To: Message-ID: On Sun, 8 Sep 2002, Bradley Baetz wrote: > Lets use mod_perl before we worry about 'experimental' perl features like > that.. Agreed. mod_perl works *today* and on everything down to... 5.00x, IIRC. 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 Sun Sep 8 17:55:34 2002 From: myk at mozilla.org (Myk Melez) Date: Sun, 08 Sep 2002 10:55:34 -0700 Subject: DBI and the shadowdb References: Message-ID: <3D7B8F16.7040704@mozilla.org> Bradley Baetz wrote: >>Btw- Are there any plans to make it possible to install a read-only >>installation of Bugzilla that directs all write requests to another >>installation. This, along with replication, would provide an quick and >>easy scalability solution (just add more boxes). >> >> >> > >Well, we could use DBD::multiplex. The problem is the definition of 'write >request', esp with consistent data, and so on. > I'm thinking of a simpler solution: a parameter designating the urlbase of the master installation. If non-empty, Bugzilla includes it in the "action" attribute of all forms whose submission results in a database write. Then users could choose (or have chosen for them via round-robin) a server to use for querying and retrieving bugs, and writes still go through a single master installation. This approach also avoids the need to open up MySQL on the master machine to other machines. -myk From myk at mozilla.org Sun Sep 8 17:58:45 2002 From: myk at mozilla.org (Myk Melez) Date: Sun, 08 Sep 2002 10:58:45 -0700 Subject: test installation with b.m.o data available Message-ID: <3D7B8FD5.8000502@mozilla.org> I once again have a test installation with b.m.o data. If you have patches you need me to test on it, mail me with bug numbers, instructions, etc. (even if you've messaged or mailed me before), and I'll start testing them tomorrow (Monday, September 8). -myk From gerv at mozilla.org Sun Sep 8 22:22:18 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 08 Sep 2002 23:22:18 +0100 Subject: Website directory structure References: Message-ID: <3D7BCD9A.7030300@mozilla.org> > I like short names, ala 'admin', 'dev', and 'test'. OK, we now have two new directories - admin and dev - and a new Localisers' Guide: http://www.bugzilla.org/dev/l10n-guide.html (you'll need to wait for the website to sync, as usual.) Gerv From bugreport at peshkin.net Mon Sep 9 14:15:17 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 09 Sep 2002 07:15:17 -0700 Subject: Bugs to fix in a 2.16.1 release??? Message-ID: <3D7CACF5.5000404@peshkin.net> http://bugzilla.mozilla.org/show_bug.cgi?id=167485 http://bugzilla.mozilla.org/show_bug.cgi?id=166023 From gerv at mozilla.org Wed Sep 11 13:59:16 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 11 Sep 2002 14:59:16 +0100 Subject: 2.18 planning Message-ID: <3D7F4C34.5090102@mozilla.org> This is the plan I posted for 2.18. I think we should be doing 1) right now. Anyone got any views? Gerv We should: 1) Discuss possible goals for 2.18 2) Decide on a timeframe for 2.18 3) See which goals we can get in that approximate timeframe 4) Prioritise those goals, and set them as goals 5) Set other big items as explicit non-goals 6) Start work 7) Release developer point releases once every month or two 8) Have a goal reassessment, short or long, at each point release Gerv From bbaetz at student.usyd.edu.au Wed Sep 11 14:25:18 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 12 Sep 2002 00:25:18 +1000 (EST) Subject: 2.18 planning In-Reply-To: <3D7F4C34.5090102@mozilla.org> Message-ID: What happened to 2.16.1?... Bradley From matty at chariot.net.au Thu Sep 12 07:26:28 2002 From: matty at chariot.net.au (MattyT) Date: 12 Sep 2002 16:56:28 +0930 Subject: 2.18 Goals Message-ID: <1031815594.20860.188.camel@megagerbil> I suppose now is a good time to take a high level overview of where we are at for 2.18 and where we might be going. As such I'll list the projects we're all working on and the status as I see them. Apologies if your really important project is missing, I did my best. We should take this discussion, work out what are 2.18 hard goals, 2.18 soft goals, and 2.20 hard goals and update the roadmap as such. Administration Rewrite (Administration Templatisation + Taint) -------------------------------------------------------------- Bug #97706 Responsible: MattyT This arose when I attempted to develop customisation resolutions by copying editkeywords.cgi to editresolutions.cgi. I quickly discovered there was substantial potential for code reuse, and set out to rewrite the code in a reusable way. As such, the administration rewrite was born. The rewrite features sortkeys and inactivity for everything, and has a schema requirement of (id, name, description, isactive, sortkey). It does not yet support product-specific fields (but probably will once I get up to the point of needing it to), nor does it support the more varied needs of editgroups and editusers (it might, it might never do, or I might make my administration system rely on a more general administration system, having a three-tiered system for these CGIs). Originally planned to be checked in along with customised resolutions, I decided it would be a simpler customised resolution patch to rewrite keywords first, giving them sortkeys and inactivity in the process. This is bug #69267. This work is almost ready. Another part of this is the moving of the localconfig enumerations into the database, and giving them descriptions, sortkeys, isactive flags and IDs, also preventing the enumeration deletion problem. This will probably be the second part, and is bug #146104. Then I will start thinking about product-specific fields. The administration rewrite is fully templatised and taint mode enabled. Hence it is a part of the templatisation + taint mode of the administration CGIs. If we don't convert all the CGIs over for 2.18, we will need to convert them over maintaining the old system. This is possibly the best plan for editgroups and editusers, but we will know better towards the end of the milestone and can wait until then. This doesn't need to be a hard 2.18 goal, but getting as much as possible in now will save T + TM work later. Back End Separation ------------------- Bug #162613 Responsible: No One/Multiple? Touted as more as a 2.20 goal than a 2.18 goal, nevertheless the recent massacre of CGI.pl and globals.pl has probably helped this a bit. Bug.pm remains to be updated and used however, and we're probably still a long way from finishing this and hence getting a nice testing suite happening. Zach indicated he may well be doing this for the new installation system, that would be a very useful place to have back end separation. Bugmail Rewrite --------------- Various Bugs Inc. Bug #26943, #125888, #97956, #113688, #93952 Responsible: MattyT/timeless? The mooted rewrite of processmail to include some nice new features such as bulk change single notifications, and to be more sane. No work has been done to my knowledge, and this is unlikely to be a 2.18 feature. However, it might be worth writing the initial bugmail template to support these features, even if processmail does not yet use them. This would prevent admins from having to change their templates later. bbaetz's modularisation of processmail (bug #124174, #140782) also probably comes under this heading. This will help windows and probably be done for 2.18. Configurable Access Policies ---------------------------- Bug #110947 Responsible: No One Touted as more of a 2.20 goal, it can probably happily stay there. The aim is to let administrators define what access different users have to bugs, rather than using a hardcoded policy. It needs to be product by product, and I think a good implementation would be to define policy records and let products refer to them, so they can be shared between products. This would involve removing the hardcoded system role "editbugs". It would become a normal group on existing installations and will possibly remain a default group for new installations. It is blocked on the new group system. Customised Email Reports ------------------------ Bug #6679 Responsible: No One Pfft, nothing has been done on customising whinemail to be more useful. Customised Fields ----------------- Bug #91037 Responsible: Non Core This one has been delayed for a while and really needs to be picked up and shepherded by a core developer. I believe it isn't "customised fields" but rather "customised enumeration type fields". Luckily a lot of fields are simply enumeration type (OS, platform, severity, priority, version, milestone), as opposed to bug reference type (dependencies), text (whiteboard, summary, URL), account (QA, assignee, CC), complicated enumeration type (status, resolution), keywords type, allocation type (votes), or other (bug #, alias). Once this is in, we can start thinking about unhardcoding our enumeration type fields, so they can be removed. We can also think about customising other types of field. I believe multi-select is supported, but don't know the status of templatisation or taint mode is here. This is part of why it's important a core developer gets involved - this is a major patch and we need to make this this fits in with where we are heading. A big issue with this is how they interact with templates. Requiring admins to edit templates when fields are added or removed, is, I think, unacceptable long term. I believe we can make our templates adjust to new fields, given there's a fixed set of field _types_. Getting the current patch in has I believe been touted as a hard 2.18 goal, apparently too many installations require it to upgrade, as it would be too much work to keep redoing their installation hacks. Customised Graphs ----------------- Bug #105491 Responsible: Gerv Rewrite of graphing so that you can graph anything (but not retrospectively). This also involves moving the graphing parameters and results into the database. This can't be checked in before customised resolutions because it expects resolution IDs, but they only arrive with customised resolutions. Unfortunately, customised resolutions can't be checked in before customised graphs either, so they need to go in at the same time. We could split these apart, but one of them would need transitional code that would be going away. Normally this would be OK, but it involves schema changes. This might need to handle stuff that isn't ID based, probably at least customised statuses won't be for 2.18, although we could use fake-IDs that aren't (yet) foreign keys. Customised Reports ------------------ Bug #12282 Responsible: Gerv Rewrite of reports.cgi to allow general bug count tables to be generated, much like query.cgi. The existing CGI was always bmo hardcoded and never worked properly. I think Gerv is dropping Most Doomed and Most Recently Doomed, seemingly even bmo doesn't use them as no one complained they didnt even work on bmo. Gerv just attached his first cut, and this is direly needed, it should be a hard 2.18 goal. I don't know whether he's planning to support stored reports for 2.18, but this should probably be a subsequent patch since it might require refactoring stored query code. I have plans to support customised indentation type reports, which are basically like query.cgi but grouped together. They would have scope for group counts and sums, and also with the ability to only show the top X within a group, but not for 2.18. Another possibility not yet being explored is also attachment and/or vote counts, so for example you could see who attached the most. Customised Resolutions ---------------------- Bug #95434 Responsible: MattyT This aims to allow you to define your own resolutions. There are 4 classes of resolution - { successful, unsuccessful, moved, duplicate }. Note you can define more than one dupe and moved resolution. It also adds inactive resolutions and sortkeys as it uses the new admin system. It is a bit bitrotten, but this is not a major problem, the blockages are however. This cannot be checked in before customised graphs, since renaming resolutions would break graphing, as the old system uses name references outside of the database. Unfortunately it also cannot be checked in after customised graphs, so they must be checked in together. This also possibly cannot be checked in before quicksearch is rewritten in perl, because the current quicksearch uses a hardcoded file called localconfig.js which the admin needs to update manually (but this is possibly not a problem because there is currently the same issue with keyword renaming I believe). Along with this, I have changed the resolution set for new installations to { FIXED, INVALID, FEATURENOTBUG, NOTWORTHIT, DUPLICATE, WORKSFORME, MOVED, MISSING, CAREFACTORZERO }. This is aimed at demonstrating possibilities, not being the final set of any installation, and is obviously not going to be the updated set of BMO once this gets in. Also REMIND and LATER are gone for new installs. This should be a 2.18 goal, we have waited long enough, and bmo wants this too. Customised Statuses ------------------- Bug #101179 Responsible: MattyT Not yet started, however will use the new administration system and likely some code and lessons gained from customised resolutions. It's probably more complicated than resolutions as you need to handle status transitions as well, but hopefully there won't be all the stuff blocking it that customised resolutions had. Unlikely to make 2.18, but one can hope. Email Interface Integration --------------------------- Bug #94850 Responsible: Non Core? Project to bring the email interface out of contrib and into mainline. It would be nice if this could use a back end API rather than its own SQL, which would mean that it would maintained better. As such, I think this shouldn't be a 2.18 goal. We'll certainly take improvements here, but I think that we really can't integrate and maintain this until we have a back end it can use. Group System Rewrite -------------------- Bug # Responsible: Joel The terminally delayed group system rewrite to get > 55 user groups. The current system includes a new feature, group inheritance (groups which are the union of other groups). There are a few arguments about how best to determine user membership in groups. Different systems of caching have been proposed, some faster, smaller or more flexible, but none seems perfect. bbaetz doesn't think we even need a caching system, at least yet. I think this should be split off into a parity patch and the group inheritance patch, allowing us to unblock bugs while giving us time to work out what caching policy we should use. At least the parity should be a hard 2.18, it is direly needed. Localisation & Internationalisation ----------------------------------- Bug #? Responsible: Gerv I have no idea what Gerv is doing here, but I suppose we can claim we have good I18N capability even if the implementation is horrid. Long term we need to reconsider gettext or similiar, and also think about whether we want field value names and descriptions to also be I18Nable in the database. I suppose the current plans for removing all user-text from the CGIs should be a hard 2.18 goal. I think other things can wait for future milestones. Mail Templatisation ------------------- Bug #125688, #148147 (? for token) Responsible: No One? One part of the full templatisation effort requires we templatise our mail output, including bugmail. I think we have already have a mail template somewhere, but we need to take a high level decision how to implement this. One main issue is how to implement headers vs. body, either in the one template or as two separate templates. How the mail transport rewrite API works affects this to a degree, but I think most of us agree separate templates are better. The other main issue issue is how to handle escaping of high-ASCII and so on in mail, we have bugs with this we should fix (eg bug #110692). I'm not really familiar with mail escaping, but I understand we need to escape headers differently from the body. Ideally this would not have to be done in the template at all, but the mail CGIs would do it automatically. These two things might dictate a separate-template implementation. Should be a hard 2.18 goal. Mail Transport Rewrite ---------------------- Bug #84876, #65101 Responsible: JayPee/Gerv? A rewrite of mail transport to make setup easier and to work in more configurations. It will use some sort of Perl module, and should therefore work under Windows, which the current system has problems with I believe. Will hopefully fix our sendmailnow problems? Should be a hard 2.18 goal. mod_perl Support ---------------- Bug #87406 Responsible: BBaetz? This is a pretty substantial change to our architecture, in get the performance benefits of running under Apache's mod_perl. I don't think much has been done in the way of this so far, and I think it should be a 2.20 goal, although new 2.18 work should attempt to be mod_perl compliant. New Install System ------------------ Bug #105854? Responsible: Zach Zach's fabled new installation system. I know little about this, other than it hopefully splits up the monolithic checksetup.pl and does some front end/back end separation. I also hope that it lets checksetup.pl use some of the reusable code we have - there is currently code in checksetup.pl that also appears elsewhere. This seems to be stalled and I hear occasionally it's bitrotten - I suggest it would be better to get this in via simple patches to avoid this, ie start by moving bits of code into modules. I don't think this should be a hard 2.18 goal, we can wait and see if it happens. Postgres Support ---------------- Bug #98304 Responsible: DKL This is quite an undertaking unfortunately. Much of the PgSQL work in under the banner of other projects. Firstly, we need to remove all enumerations from the database as they are MySQL-specific. This is taking place under the localconfig enumerations part of the admin rewrite, under customised resolutions, and under customised statuses. It is the difficulty in getting the last in during 2.18 that may make PgSQL support unable to arrive in 2.18. One transitional possibility is simply to use a status_id field which has hardcoded meaning, and isn't (yet) a foreign key. Secondly, there is a need to handle the simple SQL dialectal issues, by using ANSI SQL and by inserting subroutines to return the relevant dialectical SQL. For example, regexps and date handling are different between the databases. Thirdly, the administration system needs to be changed to handle PgSQL. PgSQL doesn't support some field types MySQL does, eg mediumtext I think. One alternative is to use lowest common denominator types, another is to be specific and emulate field types with the closest possible field type. Fourthly, PgSQL has a dramatically different locking & transaction system, that is incompatible with the code we use now. I think bbaetz is mooting a move to requiring MySQL transactions at some stage, possibly requiring MySQL 4. This would be quite unlikely for 2.18 however, and would probably be 2.20 at the earliest. It's probably possible to get some transitional code in which does the appropriate transactioning when it discovers locks. This wouldn't solve many of our lack-of-transaction problems, but it could get in for 2.18 and work under PgSQL. I'm not sure how compatible this is with bbaetz's DBI plans, however. Fifthly, I don't believe PgSQL supports groupset math, so the new group system is also required. I don't think this should be a hard 2.18 goal, but we should definitely try hard here. Product Group Rewrite --------------------- Bug #147275 Responsible: Joel The current product group system has major problems. Firstly, the mechanism of finding product groups by name is not discoverable. Secondly, it is inflexible, you can't share groups between products, and you can't specify the entry parameter on a product by product basis. Thirdly, you can't specify that a product group can never be removed. This rewrite will solve these problems. The product group will be defined on the product page, and can be any group. You can also specify a different group for entry. Further features include specifying the difference between a bug restriction being by default, and being required and not able to be removed, and also be not allowed. This is all on a product by product basis. The exact features have not been decided yet, but it will certainly be a quantum leap over what we have. This is blocked on the new group system. I hope this will make 2.18, but don't think it should be a hard goal. Shadow Database Rewrite ----------------------- Bug #124589 Responsible: BBaetz The current shadow database easily gets too out of sync, and can get corrupted. This aims to rewrite the shadow database using MySQL replication. There will be a transition period on BMO so they can go back to the old implementation if problems occur. But after this, the old implementation will be dropped back into the pile of primordial sludge it came from. This will likely all occur before 2.18, unless someone yells. No one has so far, as there were release notes of deprecation in 2.16 and 2.14.2 to this effect. This is also a necessary condition for us to use DBI placeholders in write SQL statements. Note that PgSQL will not need a shadow database due to its MVCC architecture, however there might be performance benefits regardless if the shadow database is on another disk (I doubt anyone would want to do this, however). String Key Removal ------------------ Bug #? Responsible: MattyT/BBaetz? We have long been using string keys for stuff such as product, component, version and milestone. String keys are slower and harder to rename (although the current code does). As such, transitioning everything over to IDs is a good plan. BBaetz has already done products and components, but has disclaimed responibility for milestones and versions. These will probably be picked up by me as a part of the administration rewrite. There is probably no reason to make this a hard goal for 2.18, but it will probably happen anyway. System Role Rewrite ------------------- Bug #147276 Responsible: Joel Rather than having specific system groups, which is kludgy, Bugzilla should have system roles that refer to groups. Originally, these roles could be params, but eventually they will become part of an access policy. Not a 2.18 requirement. Watching Rewrite ---------------- Bug #76794, #14137, #34787, #128839 Responsible: Jake/Myk? People want to be able to watch products, components, keywords, etc. Probably won't be 2.18, as much as I desperately want a Bugzilla product watch. -- 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 matty at chariot.net.au Thu Sep 12 07:35:37 2002 From: matty at chariot.net.au (MattyT) Date: 12 Sep 2002 17:05:37 +0930 Subject: 2.18 Goals In-Reply-To: <1031815594.20860.188.camel@megagerbil> References: <1031815594.20860.188.camel@megagerbil> Message-ID: <1031816142.20864.193.camel@megagerbil> On Thu, 2002-09-12 at 16:56, MattyT wrote: > We should take this discussion, work out what are 2.18 hard goals, 2.18 > soft goals, and 2.20 hard goals and update the roadmap as such. Here's a summary of what I think: > Administration Rewrite (Administration Templatisation + Taint) > -------------------------------------------------------------- Admin T+T: Hard 2.18, Admin Rewrite: Soft 2.18 > Back End Separation > ------------------- Hard 2.20 > Bugmail Rewrite > --------------- Soft 2.20 > Configurable Access Policies > ---------------------------- Hard 2.20 > Customised Email Reports > ------------------------ Soft 2.20 > Customised Fields > ----------------- Hard 2.18 > Customised Graphs > ----------------- Hard 2.18 > Customised Reports > ------------------ Hard 2.18 > Customised Resolutions > ---------------------- Hard 2.18 > Customised Statuses > ------------------- Soft 2.18 > Email Interface Integration > --------------------------- Hard 2.20 > Group System Rewrite > -------------------- Hard 2.18 > Localisation & Internationalisation > ----------------------------------- Hard 2.18 > Mail Templatisation > ------------------- Hard 2.18 > Mail Transport Rewrite > ---------------------- Hard 2.18 > mod_perl Support > ---------------- Hard 2.20 > New Install System > ------------------ Soft 2.18 > Postgres Support > ---------------- Soft 2.18 > Product Group Rewrite > --------------------- Soft 2.18 > Shadow Database Rewrite > ----------------------- Soft 2.18 > String Key Removal > ------------------ Soft 2.18 > System Role Rewrite > ------------------- Soft 2.18 > Watching Rewrite > ---------------- Soft 2.18 -- 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 preed at sigkill.com Thu Sep 12 09:24:18 2002 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 12 Sep 2002 02:24:18 -0700 (PDT) Subject: 2.18 Goals In-Reply-To: <1031815594.20860.188.camel@megagerbil> Message-ID: Without looking at all the bugs, from the descriptions, I'd say... On 12 Sep 2002, MattyT wrote: > Back End Separation > ------------------- > > Bug #162613 Responsible: No One/Multiple? I can help with this... > Bugmail Rewrite > --------------- > > Various Bugs Inc. Bug #26943, #125888, #97956, #113688, #93952 > Responsible: MattyT/timeless? > > The mooted rewrite of processmail to include some nice new features such > as bulk change single notifications, and to be more sane. I'll probably help with that, too... > Email Interface Integration > --------------------------- > > Bug #94850 Responsible: Non Core? Probably me, too... > Mail Templatisation > ------------------- > Mail Transport Rewrite > ---------------------- These are both mine. 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 Thu Sep 12 12:19:04 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Sep 2002 13:19:04 +0100 Subject: 2.18 Goals References: <1031815594.20860.188.camel@megagerbil> Message-ID: <3D808638.90801@mozilla.org> > Another part of this is the moving of the localconfig enumerations into > the database, and giving them descriptions, sortkeys, isactive flags and > IDs, also preventing the enumeration deletion problem. This will > probably be the second part, and is bug #146104. Doesn't moving localconfig to the DB fit in with customised fields? > The administration rewrite is fully templatised and taint mode enabled. I am of the view that total templatisation and l10nability should be a hard 2.18 target. If admin can be done, I've got the rest under control. > I believe it isn't "customised fields" but rather "customised > enumeration type fields". IMO, any decent custom fields patch should be able to support: - enumerations (multi and single) - text - email address As far as I can see, these are the three most common requested types. > A big issue with this is how they interact with templates. Requiring > admins to edit templates when fields are added or removed, is, I think, > unacceptable long term. I believe we can make our templates adjust to > new fields, given there's a fixed set of field _types_. I think this is unlikely to please anyone. I don't think it's unreasonable to ask an admin to add the UI for a new field type to e.g. the query template, as long as we do _everything_ else (notice it's there, do the right thing etc.) Any sort of auto-generated layout is bound to suck. [Generic Graphing] > This can't be checked in before customised resolutions because it > expects resolution IDs, but they only arrive with customised > resolutions. That's not actually true - it'll store query URLs, which will still use the resolution name (like query URLs involving products still use the product name.) We can get this in before custres. > Customised Reports > ------------------ In hand, patch posted, review requested. Shouldn't take too long. > I don't know whether he's planning to support stored reports for 2.18, > but this should probably be a subsequent patch since it might require > refactoring stored query code. Stored will be a subsequent patch. > I have plans to support customised indentation type reports, which are > basically like query.cgi but grouped together. They would have scope > for group counts and sums, and also with the ability to only show the > top X within a group, but not for 2.18. You need to check out my current implementation and make sure I haven't used any too-generic names or burned any bridges that'll make this difficult. > Along with this, I have changed the resolution set for new installations > to { FIXED, INVALID, FEATURENOTBUG, NOTWORTHIT, DUPLICATE, WORKSFORME, > MOVED, MISSING, CAREFACTORZERO }. MISSING? And what's the difference between NOTWORTHIT and CAREFACTORZERO? [Total Localisability] > I have no idea what Gerv is doing here, but I suppose we can claim we > have good I18N capability even if the implementation is horrid. There are several strands to this: - Templatisation of everything. We need the admin CGIs done, and email - apart from that, we are there. - Error message localisation. We have done all the calls which use Throw*Error; we now need to convert the 100+ calls to DisplayError. That won't take more than a few hours. So the big blocker to total l10nability is the admin CGI templatisation. If that happens, this will all happen in 2.18. > Long term we need to reconsider gettext or similiar, and also think > about whether we want field value names and descriptions to also be > I18Nable in the database. We don't need gettext - we are getting along perfectly well without it. Field names should not be localisable; field descriptions should be in the templates (centralised; currently they aren't, I noticed last night) and not the database. > Mail Templatisation > ------------------- I'll take responsibility for this, but we should resolve the major mail bug first (84876). > Mail Transport Rewrite > ---------------------- > > Bug #84876, #65101 Responsible: JayPee/Gerv? Dave needs to assess the two possible implementations and make a decision. He's needed to do that for ages :-) We recently refreshed the patches, and are still waiting. :-P > Will hopefully fix our sendmailnow problems? Yep. Gerv From bugreport at peshkin.net Thu Sep 12 12:24:02 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 12 Sep 2002 05:24:02 -0700 Subject: 2.18 Goals References: <1031815594.20860.188.camel@megagerbil> Message-ID: <3D808762.1010908@peshkin.net> Since I am responsible for the product group rewrite and it is direly needed (by me), I think we should take it as a hard goal. My intention with the product groups is to leave room so it can be readily extended into "foo" groups in addition to product groups should someone decide what "foo" is in the future. -Joel From bbaetz at student.usyd.edu.au Thu Sep 12 12:34:31 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 12 Sep 2002 22:34:31 +1000 (EST) Subject: 2.18 Goals In-Reply-To: <3D808638.90801@mozilla.org> Message-ID: On Thu, 12 Sep 2002, Gervase Markham wrote: > > Another part of this is the moving of the localconfig enumerations into > > the database, and giving them descriptions, sortkeys, isactive flags and > > IDs, also preventing the enumeration deletion problem. This will > > probably be the second part, and is bug #146104. > > Doesn't moving localconfig to the DB fit in with customised fields? Well... Having customised fields in will eventually allow us to move some of the stuff in localconfig into the db. I don't think that this first round of patches goes that far, though. > > > The administration rewrite is fully templatised and taint mode enabled. > > I am of the view that total templatisation and l10nability should be a > hard 2.18 target. If admin can be done, I've got the rest under control. > Admin really needs to be done. The code is a mess, and trying to touch it is impossible. Also, mod_perl doesn't allow us to run some scripts in taint and some not, so these would have to be left un-mod-perl'd. > > I believe it isn't "customised fields" but rather "customised > > enumeration type fields". > > IMO, any decent custom fields patch should be able to support: > - enumerations (multi and single) > - text > - email address > > As far as I can see, these are the three most common requested types. > The first round only does the first two, IIRC. > > A big issue with this is how they interact with templates. Requiring > > admins to edit templates when fields are added or removed, is, I think, > > unacceptable long term. I believe we can make our templates adjust to > > new fields, given there's a fixed set of field _types_. > > I think this is unlikely to please anyone. I don't think it's > unreasonable to ask an admin to add the UI for a new field type to e.g. > the query template, as long as we do _everything_ else (notice it's > there, do the right thing etc.) Any sort of auto-generated layout is > bound to suck. > Not really. We do it currently, don't forget. Whether its read in from teh versioncache, or from the db shouldn't matter. Bradley From bbaetz at student.usyd.edu.au Thu Sep 12 12:59:29 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 12 Sep 2002 22:59:29 +1000 (EST) Subject: 2.18 Goals In-Reply-To: <1031815594.20860.188.camel@megagerbil> Message-ID: On 12 Sep 2002, MattyT wrote: > Back End Separation > ------------------- > > Bug #162613 Responsible: No One/Multiple? > We're slowly doing this. I have half of a set of pages to make everything which just reads bugs (ie show_bug) use Bug.pm, and have removed bug_form.pl. Its only half, and my bugzilla hacking time is limited for teh next few months. Some of the stuff lke moving tempaltes into modules can be done after that. > [processmail rewrite] My personal opinion would be to do the below as an evil evil hack, then rm Bugzilla/ProcessMail.pm (or whatever we call the thing) and start from scratch. Do this either before or after emailprefs table goes in. Seriously, this code sucks so badly, and is so filled with evil evil hacks, that a rewrite of most of the stuff is probably the best way to go. Keep some stuff like myk's recent filtering rewrite, but redo it totally to use the activity log, now that we have it It would _greatly_ simplify the code, and make later modifications a _lot_ easier. > bbaetz's modularisation of processmail (bug #124174, #140782) also > probably comes under this heading. This will help windows and probably > be done for 2.18. > JayPee was going to trake this over, IIRC. I have very little time... > Configurable Access Policies > ---------------------------- > > Bug #110947 Responsible: No One > joel had most of this going before I got him to remove some of the features from his groups patch so that it would be reviewed this year... > Customised Graphs > ----------------- > > Bug #105491 Responsible: Gerv > > Rewrite of graphing so that you can graph anything (but not > retrospectively). This also involves moving the graphing parameters and > results into the database. Why not retrospectivly? We have a patch for collectstats + regeneration sitting in bugzilla... > > This can't be checked in before customised resolutions because it > expects resolution IDs, but they only arrive with customised > resolutions. Unfortunately, customised resolutions can't be checked in > before customised graphs either, so they need to go in at the same time. Why can't custres be checked in before this? The other way arround would proably be painful, but getting the current charting to work with custres would just involve some resolution_id_to_name calls somewhere > > We could split these apart, but one of them would need transitional code > that would be going away. Normally this would be OK, but it involves > schema changes. > It would need transitional code, but I'm not sure that it would need a lot. > Customised Resolutions > ---------------------- > > Bug #95434 Responsible: MattyT Bug 94534, actually. > > This aims to allow you to define your own resolutions. There are 4 > classes of resolution - { successful, unsuccessful, moved, duplicate }. > Note you can define more than one dupe and moved resolution. It also > adds inactive resolutions and sortkeys as it uses the new admin system. the patch on that bug is really incomplete, but that description sounds like its trying to do quite a lot. I think that you should leave out MOVED for the moment - theres a bug open somewhere on allowing moving to multiple installations, not to mention that move.pl is probably in want of a rewrite soonish. > > This also possibly cannot be checked in before quicksearch is rewritten > in perl, because the current quicksearch uses a hardcoded file called > localconfig.js which the admin needs to update manually (but this is > possibly not a problem because there is currently the same issue with > keyword renaming I believe). Well, we could just have the js not do validation.... > This should be a 2.18 goal, we have waited long enough, and bmo wants > this too. Not unless a patch appears. We want 2.18 this year.... :) > mod_perl Support > ---------------- > > Bug #87406 Responsible: BBaetz? > > This is a pretty substantial change to our architecture, in get the > performance benefits of running under Apache's mod_perl. > > I don't think much has been done in the way of this so far, and I think > it should be a 2.20 goal, although new 2.18 work should attempt to be > mod_perl compliant. Yeah, I'm slowly moving us there, in my free time (Ha!) > Postgres Support > ---------------- > Secondly, there is a need to handle the simple SQL dialectal issues, by > using ANSI SQL and by inserting subroutines to return the relevant > dialectical SQL. For example, regexps and date handling are different > between the databases. We need to remove the timestamp fields, but we should do that anyway for other reasons - see the bug on it. I don't think we use regexps anywhere, do we? The only place is the query screen, right? > > Thirdly, the administration system needs to be changed to handle PgSQL. > PgSQL doesn't support some field types MySQL does, eg mediumtext I > think. One alternative is to use lowest common denominator types, > another is to be specific and emulate field types with the closest > possible field type. It does, it just uses different names. There are some differences, but its nothign to be worried about, since we don't use any of the obscure tyeps with this problem. > > Fourthly, PgSQL has a dramatically different locking & transaction > system, that is incompatible with the code we use now. I think bbaetz > is mooting a move to requiring MySQL transactions at some stage, > possibly requiring MySQL 4. This would be quite unlikely for 2.18 > however, and would probably be 2.20 at the earliest. Having the current locking code work is probably not that hard. Having it work performantly is. I think that after some of the backend separation shakes out, then this may be easier. > > It's probably possible to get some transitional code in which does the > appropriate transactioning when it discovers locks. This wouldn't solve > many of our lack-of-transaction problems, but it could get in for 2.18 > and work under PgSQL. I'm not sure how compatible this is with bbaetz's > DBI plans, however. The DBI will, to a large extent, make discovering what is being done hard. Not impossible (and fairly easy for LOCK, in fact), but in general its Hard. > I don't think this should be a hard 2.18 goal, but we should definitely > try hard here. This won't make 2.18. For a start, we require the pgsql version currently in beta for modification stuff. This can, however, happen gradually, so we'll see. > Shadow Database Rewrite > ----------------------- > > Bug #124589 Responsible: BBaetz > > The current shadow database easily gets too out of sync, and can get > corrupted. This aims to rewrite the shadow database using MySQL > replication. > Its not actually a rewrite, its more a removal. This is done, and awaiting myk's testing. > Watching Rewrite > ---------------- > > Bug #76794, #14137, #34787, #128839 Responsible: Jake/Myk? This should be done after the processmail rewrite for simplictly, although thats probably not required. It needs emailprefs, but after that the code is trivial. The UI is not, though.... Bradley From gerv at mozilla.org Thu Sep 12 13:09:57 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Sep 2002 14:09:57 +0100 Subject: 2.18 Goals References: Message-ID: <3D809225.9080105@mozilla.org> > Not really. We do it currently, don't forget. Whether its read in from teh > versioncache, or from the db shouldn't matter. Where on the query page/show_bug page do we autogenerate layout for an arbitrary number of fields? Yes, we have [% IF (Param('useqacontact') %] but that's not the same thing. Gerv From bbaetz at student.usyd.edu.au Thu Sep 12 13:24:34 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 12 Sep 2002 23:24:34 +1000 (EST) Subject: 2.18 Goals In-Reply-To: <3D809225.9080105@mozilla.org> Message-ID: On Thu, 12 Sep 2002, Gervase Markham wrote: > > Not really. We do it currently, don't forget. Whether its read in from teh > > versioncache, or from the db shouldn't matter. > > Where on the query page/show_bug page do we autogenerate layout for an > arbitrary number of fields? Yes, we have [% IF (Param('useqacontact') %] > but that's not the same thing. > > Gerv Ah, sorry, I misunderstood. We do it for an arbitary number of _values_ (ie products/etc) which is what I thought you were referring to. My solution (for query.cgi and show_bug.cgi) I mentioned on IRC at one point was to have the BLOCK for displaying an element record that its been shown in a hash, and then at the bottom, we just display all undisplayed form elements in alphabetical order. This would then 'work', but an admin would easily reorder stuff by adding the appropriate field in place. BRadley From matty at chariot.net.au Thu Sep 12 14:04:39 2002 From: matty at chariot.net.au (MattyT) Date: 12 Sep 2002 23:34:39 +0930 Subject: 2.18 Goals In-Reply-To: <3D808638.90801@mozilla.org> References: <1031815594.20860.188.camel@megagerbil> <3D808638.90801@mozilla.org> Message-ID: <1031839539.20864.206.camel@megagerbil> On Thu, 2002-09-12 at 21:49, Gervase Markham wrote: > Doesn't moving localconfig to the DB fit in with customised fields? It could do, I hadn't really considered this. My current plan is to get the customised fields to use the administration rewrite if possible - so it would be an alternate route to the same thing. > IMO, any decent custom fields patch should be able to support: > - enumerations (multi and single) > - text > - email address And there is also something to say for simple patches. There's no need to save the world in one patch. > I think this is unlikely to please anyone. I don't think it's > unreasonable to ask an admin to add the UI for a new field type to e.g. > the query template, as long as we do _everything_ else (notice it's > there, do the right thing etc.) Any sort of auto-generated layout is > bound to suck. It doesn't have to be perfect. As BBaetz said elsewhere, admins are free to fix up the template if they don't like it, all we need is a reasonable layout to get an installation up to speed quickly. We don't even need to put all unrecognised fields at the bottom. Grouping all fields of the same type together is a way of providing a decent layout, possibly better than the one we have now. > That's not actually true - it'll store query URLs, which will still use > the resolution name (like query URLs involving products still use the > product name.) We can get this in before custres. Then I'm not sure why you said you could resolve the renaming problem. Sure, we could handle query URLs, but current custres doesn't do this for stored queries for example. Query URLs are a dead end that we should be expunging from the code base, not adding to. But I suppose it is OK as a transitional thing. It renews my enthusiasm for rearchitecting query URLs, however. > > I have plans to support customised indentation type reports, which are > > basically like query.cgi but grouped together. They would have scope > > for group counts and sums, and also with the ability to only show the > > top X within a group, but not for 2.18. > You need to check out my current implementation and make sure I haven't > used any too-generic names or burned any bridges that'll make this > difficult. I will hopefully get around to this. > > Along with this, I have changed the resolution set for new installations > > to { FIXED, INVALID, FEATURENOTBUG, NOTWORTHIT, DUPLICATE, WORKSFORME, > > MOVED, MISSING, CAREFACTORZERO }. > MISSING? And what's the difference between NOTWORTHIT and CAREFACTORZERO? MISSING means the URL referenced is 404 or such. Perhaps it should become part of NOINFO, a more general resolution for bugs that have sat in NEEDINFO status with no info supplied. But that probably shouldn't be done until NEEDINFO is here, ie customised statuses are here. NOTWORTHIT is for rejecting RFEs in non-OSS projects. CAREFACTORZERO is more of a plain insult. > We don't need gettext - we are getting along perfectly well without it. We also have had no experience with localisers keeping their templates up to date or not. > Field names should not be localisable; field descriptions should be in > the templates (centralised; currently they aren't, I noticed last night) > and not the database. I am referring to field _value_ names and descriptions, not field names and descriptions. -- 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 matty at chariot.net.au Thu Sep 12 14:19:26 2002 From: matty at chariot.net.au (MattyT) Date: 12 Sep 2002 23:49:26 +0930 Subject: 2.18 Goals In-Reply-To: References: Message-ID: <1031840434.20859.222.camel@megagerbil> On Thu, 2002-09-12 at 22:29, Bradley Baetz wrote: >> Rewrite of graphing so that you can graph anything (but not >> retrospectively). This also involves moving the graphing parameters and >> results into the database. > Why not retrospectivly? We have a patch for collectstats + regeneration > sitting in bugzilla... Retrospectivity merely isn't part of the customised graphs project. That's not to say it won't be done, but that it won't be done here. I do however have misgivings about retrospectivity, given bug activity has numerous bugs, both the truncation bug we had, and the lack of recording renamings by administrators. >> This can't be checked in before customised resolutions because it >> expects resolution IDs, but they only arrive with customised >> resolutions. Unfortunately, customised resolutions can't be checked in >> before customised graphs either, so they need to go in at the same time. > Why can't custres be checked in before this? The other way arround would > proably be painful, but getting the current charting to work with custres > would just involve some resolution_id_to_name calls somewhere The problem is that the current system keys things of name rather than ID, and it would be very difficult for custres to try and touch this stuff. I forget the specifics, but I remember this way was a lot better (or so I thought before tonight). >> We could split these apart, but one of them would need transitional code >> that would be going away. Normally this would be OK, but it involves >> schema changes. > It would need transitional code, but I'm not sure that it would need a > lot. Maybe, but I reject the idea of transitional schema changes we have to support but never actually use. There are probably plans that could avoid this, but I've yet to hear a good one. Now is probably a good time to discuss this, I suggest you look at the old charting system. > the patch on that bug is really incomplete, That's because it's old, the work moved onto CUST_RES_BRANCH a long time ago. The branch is the latest, except for the admin architecture which I might have changed on my hard disk for the keywords rearchitecture. However it is out of date with HEAD, for example stuff is still in template/default. Most of my energy is hence on the admin rewrite of keywords ATM. > but that description sounds > like its trying to do quite a lot. I think that you should leave out MOVED > for the moment - theres a bug open somewhere on allowing moving to > multiple installations, not to mention that move.pl is probably in want of > a rewrite soonish. It's all done - I originally envisaged DUPLICATE and MOVED having hardcoded IDs, but I discovered it was actually so much work to do well it was easier to do things this way. Separate moving work can happen on separate patches. >> This also possibly cannot be checked in before quicksearch is rewritten >> in perl, because the current quicksearch uses a hardcoded file called >> localconfig.js which the admin needs to update manually (but this is >> possibly not a problem because there is currently the same issue with >> keyword renaming I believe). > Well, we could just have the js not do validation.... I believe the problem isn't validation, it's taking a piece of text and understanding what field it's from. I could be wrong, however. > Not unless a patch appears. We want 2.18 this year.... :) It is pretty much ready. The hard part is everything keeps shifting, and it would break things by being checked in. > The DBI will, to a large extent, make discovering what is being done hard. > Not impossible (and fairly easy for LOCK, in fact), but in general its > Hard. This worries me a bit, but we can always add front end subs for special situations, especially for transactions/locking as my original plan was. The hard part would be ensuring we use the front ends, however. > Its not actually a rewrite, its more a removal. This is done, and awaiting > myk's testing. I call adding code and removing code that do pretty much the same thing a "rewrite". Kind of like new and old email tech coexisted for a time. -- 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 louie at ximian.com Thu Sep 12 14:41:42 2002 From: louie at ximian.com (Luis Villa) Date: 12 Sep 2002 10:41:42 -0400 Subject: 2.18 Goals In-Reply-To: References: Message-ID: <1031841702.3330.21.camel@marvin.boston.ximian.com> On Thu, 2002-09-12 at 08:59, Bradley Baetz wrote: > On 12 Sep 2002, MattyT wrote: > > > Back End Separation > > ------------------- > > > > Bug #162613 Responsible: No One/Multiple? > > > > We're slowly doing this. I have half of a set of pages to make everything > which just reads bugs (ie show_bug) use Bug.pm, and have removed > bug_form.pl. Its only half, and my bugzilla hacking time is limited for > teh next few months. Is this in CVS somewhere? Luis From jacob.steenhagen at us.army.mil Thu Sep 12 15:29:44 2002 From: jacob.steenhagen at us.army.mil (PFC Steenhagen, Jacob) Date: Thu, 12 Sep 2002 11:29:44 -0400 Subject: 2.18 Goals References: <1031815594.20860.188.camel@megagerbil> Message-ID: <3D80B2E8.601@us.army.mil> MattyT wrote: >Watching Rewrite >---------------- > >Bug #76794, #14137, #34787, #128839 Responsible: Jake/Myk? > >People want to be able to watch products, components, keywords, etc. > >Probably won't be 2.18, as much as I desperately want a Bugzilla product >watch. > > If I can get some time to work on bug 73665 ( http://bugzilla.mozilla.org/show_bug.cgi?id=emailprefs ) then the product watch should be really easy being that bug 43600 is done. IIRC, all I have left to do on this is processmail and some minor stuff (like not using a global variable that's I currently have being set in globals.pl). From afranke at ags.uni-sb.de Thu Sep 12 15:54:37 2002 From: afranke at ags.uni-sb.de (Andreas Franke) Date: Thu, 12 Sep 2002 17:54:37 +0200 Subject: 2.18 Goals In-Reply-To: Your message of "12 Sep 2002 16:56:28 +0930." <1031815594.20860.188.camel@megagerbil> Message-ID: <200209121554.RAA28029@ags.uni-sb.de> > This also possibly cannot be checked in before quicksearch is rewritten > in perl, because the current quicksearch uses a hardcoded file called > localconfig.js which the admin needs to update manually (but this is > possibly not a problem because there is currently the same issue with > keyword renaming I believe). ... >> Well, we could just have the js not do validation.... > I believe the problem isn't validation, it's taking a piece of text and > understanding what field it's from. I could be wrong, however. You're right, that's the problem. But I don't think that the quicksearch rewrite should hold up anything; IMO we can afford to require admins who want quicksearch to work on their installation to manually update their localconfig.js . Of course, it would be nice if someone with perl knowledge could review the patch at http://mozilla.flowerday.cx , see bug 70907 comment #27 and #28 . The code has been there for quite a while. Since it's not an attachment, I'm not sure how to request review for it with the request tracker... ;-) Great to see the planning for 2.18. Cheers, Andreas From myk at mozilla.org Thu Sep 12 19:45:18 2002 From: myk at mozilla.org (Myk Melez) Date: Thu, 12 Sep 2002 12:45:18 -0700 Subject: 2.18 Goals References: <1031815594.20860.188.camel@megagerbil> Message-ID: <3D80EECE.8060807@mozilla.org> MattyT wrote: >I suppose now is a good time to take a high level overview of where we >are at for 2.18 and where we might be going. As such I'll list the >projects we're all working on and the status as I see them. Apologies >if your really important project is missing, I did my best. > > Add to this list the request tracker, a new version of which is now in the review stages. http://bugzilla.mozilla.org/show_bug.cgi?id=request-tracker A description of the new version is available as an attachment on the bug: http://bugzilla.mozilla.org/attachment.cgi?id=98820&action=view This patch should be going into 2.18. -myk From jeff.hedlund at matrixsi.com Thu Sep 12 21:44:27 2002 From: jeff.hedlund at matrixsi.com (Jeff Hedlund) Date: Thu, 12 Sep 2002 17:44:27 -0400 Subject: 2.18 Goals References: <1031815594.20860.188.camel@megagerbil> Message-ID: <3D810ABB.1090705@matrixsi.com> MattyT wrote: > I suppose now is a good time to take a high level overview of where we > are at for 2.18 and where we might be going. As such I'll list the > projects we're all working on and the status as I see them. Apologies > if your really important project is missing, I did my best. And what about the time tracking bug, bug 24789? http://bugzilla.mozilla.org/show_bug.cgi?id=24789 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 Sep 12 22:21:39 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Fri, 13 Sep 2002 08:21:39 +1000 (EST) Subject: 2.18 Goals In-Reply-To: <1031841702.3330.21.camel@marvin.boston.ximian.com> Message-ID: On 12 Sep 2002, Luis Villa wrote: > On Thu, 2002-09-12 at 08:59, Bradley Baetz wrote: > > On 12 Sep 2002, MattyT wrote: > > > > > Back End Separation > > > ------------------- > > > > > > Bug #162613 Responsible: No One/Multiple? > > > > > > > We're slowly doing this. I have half of a set of pages to make everything > > which just reads bugs (ie show_bug) use Bug.pm, and have removed > > bug_form.pl. Its only half, and my bugzilla hacking time is limited for > > teh next few months. > > Is this in CVS somewhere? No. That patch is simple, but its going to break when groups goes in, so I'm waiting for that to attach it. Bradley From myk at mozilla.org Thu Sep 12 23:06:33 2002 From: myk at mozilla.org (Myk Melez) Date: Thu, 12 Sep 2002 16:06:33 -0700 Subject: Performance Message-ID: <3D811DF9.8030007@mozilla.org> When reviewing the big schema-changing patches going into Bugzilla 2.18, it's imperative for us to keep an eye out for performance regressions and flunk patches that produce significant ones. It's easy for a patch to regress performance when changing the schema if the patch author doesn't pay careful attention to the structure and frequency of their SELECT statements and use of indexes. Large installations like b.m.o are already straining under the weight of recent regressions, and we shouldn't let any significant ones slip through in the next cycle. -myk From matty at chariot.net.au Fri Sep 13 06:18:36 2002 From: matty at chariot.net.au (MattyT) Date: 13 Sep 2002 15:48:36 +0930 Subject: Configurable Access On Value Transitions? Message-ID: <1031897935.28178.162.camel@megagerbil> Problem ------- ( Configurable Access Policy Proposal ) > So what I am permitted to do would never vary by what > state something is in... only by who I am and what it is?? This is a good time to discuss what we are planning to do here. The issue is one of "transitions" between field values, and whether you can define a separate group that can do each (ie have different roles for different transitions). A corollary of being able to set a group on a transition is that you can prevent it all together. Plans ----- Now, this is definitely the plan for customised statuses, ie there is a role from status A to status B. To see its usefulness, consider RESOLVED->VERIFIED only doable by the QA contact. The keywords field requires you to bend your mind a little bit. I reject the notion we should have a role for the keywords field. Keywords isn't really a "field". In a very real sense, each keyword is a field unto itself,and deserves a separate policy. As such, a keyword is a boolean field, having two transitions, and therefore two roles, add and remove. Hence it's not suprising to find bug #167013. This is really needed, for approval keywords and so on. However it has not been planned for other fields. For resolutions, I considered it, but it definitely is not a part of custres. That is, only certainly people can use certain resolutions. A further complication is certain resolutions might only be possible from certain statuses (eg resolution NOINFO from status NEEDINFO). But that complication is perhaps overkill. This is useful I believe, for example only certain people would be allowed to make a NOTWORTHIT decision. But I don't think it's high priority in any sense. But what about other fields? Issues ------ Other fields - is it useful, is it needed? Consider especially that we will probably be getting customised fields sometime in the short- to mid-term, so new possibilities arise. If we consider there to be no good reason to do it now, what problems might it cause if we do a per-field implementation of access policies and want to change to per-transition later? Transition Roles Vs. Product Specifism -------------------------------------- Yesterday I mentioned the fact that each field should have a can-change role, for _each_ product. The Mozilla access policy and Bugzilla access policy would be different, for example for Target Milestone. While assignee and so on can change in each case, a different group can also do it in each case (Mozilla - managers, drivers, Bugzilla - me, dave). But what if we have transition roles on non-product specific fields? For status, it's problematic. Perhaps status should be product-specific, but it isn't at the moment. And that raises the question - how could we have transition roles AND product specifism? - Do we make it so there is a different set of transition roles for each product, meaning the transitions are product specific yet the values aren't? - Do we reject product specificism for just the status field, in essence giving a slight regression over a per-field system? - Do we keep both a product-specific per-field role and global transition role, and say you can do the transition if you can do the transition (determined product specific) and change the field (determined globally)? Urgh. The other field we're doing transitions on, keywords, is a lot easier however. While there aren't product-specific keywords yet, you can essentially have them by convention. If you want a different access policy for a keyword in different products, split into different keywords. If we have transition roles on general non-product-specific fields, the problem becomes worse. We can't do without product-specific access policies. Product-specific fields are less of a problem. The transitions would obviously product specific. And finally, does all this mean we should make the changes to let all fields be product-specific (and -inspecific if the admin wants), before doing transition roles, including for status? I suppose the transition role feature could (and maybe should) be dropped off the initial customised statuses patch. If anyone wants details on what I think about making all fields product specific, how we can implement this, how we can make it flexible, and how we can make it easily administerable, let me know and I'll post another message. Implementation -------------- Even if we nix general transition roles, we need to consider an implementation for statuses. The admin only has to turn on transition roles if they want, this would prevent overly complicating the administration side as well as draining performance, as you need to load in allowable transitions. There are two possibilities for implementation I see. The first is to enumerate all the transitions. This gives us 2^N possibilities for fields using transition roles, although disallowed possibilities don't need to have records. As well as the record space, this implementation has the disadvantage that total enumeration of transitions is only possible for enumeration type fields. The second possibility for implementation is a match-rule chain implementation, like mail filters or firewall setup. This is a sequential list of rules, where once a rule-condition is matched, we get the result from the rule and quit. Because the records are ordered, we can have rules to match transitions like X -> Anything. If the records were not ordered, we would need to make sure the transitions were distinct. This can save space and make administration easier. It also allows transitions on non-enumeration fields, for example regexp matches on text fields. A disadvantage is that you need to have UI and code for adding, removing and reordering rules, which could have been avoided in the first implementation by displaying everything. Another is you need to maintain "sortkeys" on the database to keep them in order, and inserting rules in the middle can be tricky. Anyone who suggests storage outside of the database will be severely flogged. Further, we might consider allow transition rules of the type value-group-> value-group, where an administrator can group values together. This might sound like overkill, but we may well implement value groups (with inheritance) as a part of an "every field can be product-specific or -inspecific" implementation. -- 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 matty at chariot.net.au Fri Sep 13 14:12:54 2002 From: matty at chariot.net.au (MattyT) Date: 13 Sep 2002 23:42:54 +0930 Subject: Performance In-Reply-To: <3D811DF9.8030007@mozilla.org> References: <3D811DF9.8030007@mozilla.org> Message-ID: <1031926386.28178.185.camel@megagerbil> On Fri, 2002-09-13 at 08:36, Myk Melez wrote: > Large installations like b.m.o are already straining under the weight of > recent regressions, and we shouldn't let any significant ones slip > through in the next cycle. What "recent regressions"? I'm not aware of any performance degradations, indeed quite the opposite (product IDs for example, should be faster). -- 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 Fri Sep 13 14:57:26 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Sep 2002 15:57:26 +0100 Subject: 2.18 Goals References: <1031815594.20860.188.camel@megagerbil> Message-ID: <3D81FCD6.4090000@mozilla.org> My views: > Administration Rewrite (Administration Templatisation + Taint) Admin T+T: Hard 2.18, Admin Rewrite: Soft 2.18 > Back End Separation Hard 2.22 :-) > Bugmail Rewrite > The mooted rewrite of processmail to include some nice new features such > as bulk change single notifications, and to be more sane. I don't see people screaming for this. 2.20. > Configurable Access Policies 2.20. Again, I haven't seen demand. > Customised Email Reports > Pfft, nothing has been done on customising whinemail to be more useful. Because it's a silly feature that no-one uses :-) A proper reporting system will mean we can ditch whinemail, because anyone who wants it can write a cron job on top of the reporting system's CSV output. > Customised Fields > This one has been delayed for a while and really needs to be picked up > and shepherded by a core developer. True. I'm hesitant to make it hard 2.18 until someone sticks their hand up. > Customised Graphs > Rewrite of graphing so that you can graph anything (but not > retrospectively). This also involves moving the graphing parameters and > results into the database. Hard 2.18. It's the next big thing after customised reports. > Customised Reports Hard 2.18. > Customised Resolutions > ---------------------- > Customised Statuses > ------------------- These has been going for ages; but is there demand for them? Seems to me we've had more requests for custom fields. > Email Interface Integration > Project to bring the email interface out of contrib and into mainline. This needs to be done by someone who actually uses it - and none of the core team's installations do, I don't think. > Group System Rewrite Hard 2.18, assuming we can make it pass review and it doesn't regress performance. Otherwise, we may have to rethink. > Localisation & Internationalisation Hard 2.18. > Mail Templatisation Hard 2.18. > Mail Transport Rewrite Hard 2.18. Every second query in the newsgroups is about getting mail to work. We need an admin interface which is as simple as "type your SMTP server name into this box". > mod_perl Support 2.20. > New Install System Very soft 2.18. I haven't seen too many people have problem with this. > Postgres Support 2.20. > Product Group Rewrite Soft 2.18. > Shadow Database Rewrite Hard 2.18, if it's a performance win. > String Key Removal Soft 2.18. Things work OK as they are. > System Role Rewrite Very soft 2.18. > Watching Rewrite 2.20. Documentation of the hacks to work around this lack would help. Gerv From myk at mozilla.org Fri Sep 13 15:37:15 2002 From: myk at mozilla.org (Myk Melez) Date: Fri, 13 Sep 2002 08:37:15 -0700 Subject: Performance References: <3D811DF9.8030007@mozilla.org> <1031926386.28178.185.camel@megagerbil> Message-ID: <3D82062B.1010709@mozilla.org> MattyT wrote: >What "recent regressions"? > The ones that went into 2.16 (primarily templatization). b.m.o is noticably slower now than it was, even after we fixed the egregrious problems post-upgrade. This slowness has a significant (if difficult to measure) impact on developer efficiency. As we implement additional features and rewrites, we need to be very careful to distinguish between performance regressions that are unavoidable because we really need the additional functionality and those that are the result of design or programming error (lack of indexes, poor schema design, looping over queries that could be run once, over-abstraction, feature bloat, etc.). Improving performance will help somewhat, but many of those improvements are still a ways off, and we don't want to spend all that additional speed anyway, so we need to hold the line as best we can. -myk From gerv at mozilla.org Fri Sep 13 17:49:17 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Sep 2002 18:49:17 +0100 Subject: Configurable Access On Value Transitions? References: <1031897935.28178.162.camel@megagerbil> Message-ID: <3D82251D.40207@mozilla.org> MattyT wrote: > Problem > ------- > > ( Configurable Access Policy Proposal ) Any sort of Configurable Access Policies will require extra database lookups for each change, to make sure the changes are allowed. I share Myk's concerns about performance; therefore, I think it's reasonable to ask: - Which Bugzilla installations want this feature? - If there is demand, do they want a variety of things or the same sort of thing? - would a simple system suffice? For example, if we rearranged CheckCanChangeField() a bit, and commented it better, many sites' needs could be accommodated by a little bit of local Perl hacking in there. e.g. if ($field eq "foo" && $from = "somevalue" && $to = "someothervalue" && !UserInGroup("somegroup") { reject = 1; } Gerv From gerv at mozilla.org Fri Sep 13 17:54:02 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Sep 2002 18:54:02 +0100 Subject: 2.18 Goals References: <200209121554.RAA28029@ags.uni-sb.de> Message-ID: <3D82263A.4000301@mozilla.org> > Of course, it would be nice if someone with perl > knowledge could review the patch at http://mozilla.flowerday.cx , > see bug 70907 comment #27 and #28 . The code has been there for quite > a while. Since it's not an attachment, I'm not sure how to > request review for it with the request tracker... ;-) File a bug for it and request review for that bug. But my initial reaction is: it needs templatising, and it doesn't conform to our coding style guidelines in various places. Also, it would be good if it didn't hard-code things in a way that meant it needed fixing for every schema change; but I don't know if that's possible. Gerv From gerv at mozilla.org Fri Sep 13 17:58:09 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Sep 2002 18:58:09 +0100 Subject: 2.18 Goals References: <1031815594.20860.188.camel@megagerbil> <3D808638.90801@mozilla.org> <1031839539.20864.206.camel@megagerbil> Message-ID: <3D822731.6080204@mozilla.org> >>That's not actually true - it'll store query URLs, which will still use >>the resolution name (like query URLs involving products still use the >>product name.) We can get this in before custres. > > Then I'm not sure why you said you could resolve the renaming problem. Renaming problem? > Sure, we could handle query URLs, but current custres doesn't do this > for stored queries for example. Query URLs are a dead end that we > should be expunging from the code base, not adding to. But I suppose it > is OK as a transitional thing. It renews my enthusiasm for > rearchitecting query URLs, however. Query URLs could start containing IDs instead of names, if that would help. But I don't know why you want them expunged - they certainly aren't going away, because they are far too useful for users (bookmarks, emails etc.) >>MISSING? And what's the difference between NOTWORTHIT and CAREFACTORZERO? > > > MISSING means the URL referenced is 404 or such. Perhaps it should That's a bit specific; a lot of installations don't have a URL field at all. I'd question whether it needs to be part of the default set. > NOTWORTHIT is for rejecting RFEs in non-OSS projects. CAREFACTORZERO is > more of a plain insult. This is rather a fine distinction. Can't we find a non-insulting name which covers both for the default set? Gerv From bugreport at peshkin.net Fri Sep 13 17:56:56 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 13 Sep 2002 10:56:56 -0700 Subject: Configurable Access On Value Transitions? References: <1031897935.28178.162.camel@megagerbil> <3D82251D.40207@mozilla.org> Message-ID: <3D8226E8.6070601@peshkin.net> Gervase Markham wrote: > > - Which Bugzilla installations want this feature? > - If there is demand, do they want a variety of things or the same > sort of thing? > - would a simple system suffice? > > For example, if we rearranged CheckCanChangeField() a bit, and > commented it better, many sites' needs could be accommodated by a > little bit of local Perl hacking in there. > Rather than inventing a new language Perl may be a very good language in which to capture site-specific rules. If we can ensure that CheckCanChangeField has easy access to sufficient information and is structured in a manner that causes site-changes not to generally conflict with BZ update, this is a perfectly good way to go. If CheckCanChangeField has the old and desired new field values available to it according to a very standard naming convention, and has a point in the code resembling..... # # # # insert site-specific rules CheckCanChangeField here # # # # Then it would be very rare that such rules would cause merge conflicts. -Joel From gerv at mozilla.org Fri Sep 13 18:02:16 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Sep 2002 19:02:16 +0100 Subject: 2.18 Goals References: Message-ID: <3D822828.8040209@mozilla.org> >>Rewrite of graphing so that you can graph anything (but not >>retrospectively). This also involves moving the graphing parameters and >>results into the database. > > Why not retrospectivly? We have a patch for collectstats + regeneration > sitting in bugzilla... Which I reviewed and everyone else has ignored :-) Although now we are on single-reviews, I could check it in - but I have no idea of its status. MattyT's point is perhaps a valid one - we've had corruption bugs in that table. But then, maybe people only care to within a few bugs what the values are. > Why can't custres be checked in before this? The other way arround would > proably be painful, but getting the current charting to work with custres > would just involve some resolution_id_to_name calls somewhere The resolution names are hard-coded into the datafile. :-( Gerv From bbaetz at student.usyd.edu.au Sat Sep 14 00:15:21 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sat, 14 Sep 2002 10:15:21 +1000 (EST) Subject: Performance In-Reply-To: <3D82062B.1010709@mozilla.org> Message-ID: On Fri, 13 Sep 2002, Myk Melez wrote: > MattyT wrote: > > >What "recent regressions"? > > > The ones that went into 2.16 (primarily templatization). b.m.o is > noticably slower now than it was, even after we fixed the egregrious > problems post-upgrade. This slowness has a significant (if difficult to > measure) impact on developer efficiency. Note that this is simple because loading hte Template module takes time (see my figures from last week-ish). mod_perl will give this all back to us, and more. The modulisation will in gneeral make things faster, by removing layers of indirection (eg DBI). In most cases, though, its just going to end up doing the same work somewhere else. Bradley From matty at chariot.net.au Sat Sep 14 02:30:07 2002 From: matty at chariot.net.au (MattyT) Date: 14 Sep 2002 12:00:07 +0930 Subject: 2.18 Goals In-Reply-To: <3D81FCD6.4090000@mozilla.org> References: <1031815594.20860.188.camel@megagerbil> <3D81FCD6.4090000@mozilla.org> Message-ID: <1031970608.28180.188.camel@megagerbil> On Sat, 2002-09-14 at 00:27, Gervase Markham wrote: >> Customised Resolutions >> ---------------------- >> Customised Statuses >> ------------------- > These has been going for ages; but is there demand for them? Seems to me > we've had more requests for custom fields. Saying there is less demand for these than custom fields isn't really saying much, we all know a lot of people want custom fields. I originally starting writing custres because I got sick of hearing people ask for it. >> Email Interface Integration > This needs to be done by someone who actually uses it - and none of the > core team's installations do, I don't think. I believe Dave has some experience with this. -- 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 matty at chariot.net.au Sat Sep 14 02:33:16 2002 From: matty at chariot.net.au (MattyT) Date: 14 Sep 2002 12:03:16 +0930 Subject: Configurable Access On Value Transitions? In-Reply-To: <3D82251D.40207@mozilla.org> References: <1031897935.28178.162.camel@megagerbil> <3D82251D.40207@mozilla.org> Message-ID: <1031970797.28176.192.camel@megagerbil> On Sat, 2002-09-14 at 03:19, Gervase Markham wrote: > Any sort of Configurable Access Policies will require extra database > lookups for each change, to make sure the changes are allowed. I share > Myk's concerns about performance; Like I said, you only need to sacrifice performance if it's actually used. Long term, we could do something like bug # > if ($field eq "foo" && > $from = "somevalue" && > $to = "someothervalue" && > !UserInGroup("somegroup") > { > reject = 1; > } It is _way_ too much to ask administrators to become Perl hackers in order to satisfy such a major, needed feature as per-field access policies. For per-transition policies, maybe it isn't. -- 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 matty at chariot.net.au Sat Sep 14 02:36:24 2002 From: matty at chariot.net.au (MattyT) Date: 14 Sep 2002 12:06:24 +0930 Subject: 2.18 Goals In-Reply-To: <3D822731.6080204@mozilla.org> References: <1031815594.20860.188.camel@megagerbil> <3D808638.90801@mozilla.org> <1031839539.20864.206.camel@megagerbil> <3D822731.6080204@mozilla.org> Message-ID: <1031970985.28180.196.camel@megagerbil> On Sat, 2002-09-14 at 03:28, Gervase Markham wrote: > Renaming problem? Renaming resolutions will break all query URLs. > Query URLs could start containing IDs instead of names, if that would > help. That's possible, but makes it really hard to roll your own. > But I don't know why you want them expunged - they certainly > aren't going away, because they are far too useful for users (bookmarks, > emails etc.) The current implementation needs to go away - we need to store IDs in the database for stored queries and so on. > That's a bit specific; a lot of installations don't have a URL field at > all. I'd question whether it needs to be part of the default set. > ... > This is rather a fine distinction. Can't we find a non-insulting name > which covers both for the default set? That's up to an administrator to decide ... these are demonstrating possibilities, not the final resolutions, and I don't think they are doing a bad job of that. -- 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 matty at chariot.net.au Sat Sep 14 02:38:39 2002 From: matty at chariot.net.au (MattyT) Date: 14 Sep 2002 12:08:39 +0930 Subject: Configurable Access On Value Transitions? In-Reply-To: <1031970797.28176.192.camel@megagerbil> References: <1031897935.28178.162.camel@megagerbil> <3D82251D.40207@mozilla.org> <1031970797.28176.192.camel@megagerbil> Message-ID: <1031971120.28127.198.camel@megagerbil> On Sat, 2002-09-14 at 12:03, MattyT wrote: > Like I said, you only need to sacrifice performance if it's actually > used. Long term, we could do something like bug # Bug #166793. -- 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 Sat Sep 14 02:52:00 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sat, 14 Sep 2002 12:52:00 +1000 (EST) Subject: 2.18 Goals In-Reply-To: <1031970985.28180.196.camel@megagerbil> Message-ID: On 14 Sep 2002, MattyT wrote: > On Sat, 2002-09-14 at 03:28, Gervase Markham wrote: > > > Renaming problem? > > Renaming resolutions will break all query URLs. Only if they're actually renamed... You may was well say that renaming products breaks query urls. Whilst true, I don't think its relevent. > > > Query URLs could start containing IDs instead of names, if that would > > help. > > That's possible, but makes it really hard to roll your own. We could alllow both (and woudl have to, for back compatability) Bradley From matty at chariot.net.au Sat Sep 14 03:38:29 2002 From: matty at chariot.net.au (MattyT) Date: 14 Sep 2002 13:08:29 +0930 Subject: 2.18 Goals In-Reply-To: References: Message-ID: <1031974710.28127.203.camel@megagerbil> On Sat, 2002-09-14 at 12:22, Bradley Baetz wrote: > Only if they're actually renamed... You may was well say that renaming > products breaks query urls. Whilst true, I don't think its relevent. Right, but with charting, it's a *MAJOR* issue if you lose data. With stored queries, you can fix your URLs. > We could alllow both (and woudl have to, for back compatability) It's possible, but I strongly question the notion that query URLs are an appropriate way to store stuff. I think much more appropriate is a field ID/ID table. Is there a way of having referential constraints to different tables from the one field (ID), depending on the values of other fields (field ID)? -- 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 Sat Sep 14 04:37:48 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sat, 14 Sep 2002 14:37:48 +1000 (EST) Subject: 2.18 Goals In-Reply-To: <1031974710.28127.203.camel@megagerbil> Message-ID: On 14 Sep 2002, MattyT wrote: > On Sat, 2002-09-14 at 12:22, Bradley Baetz wrote: > > > Only if they're actually renamed... You may was well say that renaming > > products breaks query urls. Whilst true, I don't think its relevent. > > Right, but with charting, it's a *MAJOR* issue if you lose data. With > stored queries, you can fix your URLs. Not if we (temporarily) require rerunning collectstats -regenerate, or have the rename process rename the graph file... > > > We could alllow both (and woudl have to, for back compatability) > > It's possible, but I strongly question the notion that query URLs are an > appropriate way to store stuff. I think much more appropriate is a > field ID/ID table. Is there a way of having referential constraints to > different tables from the one field (ID), depending on the values of > other fields (field ID)? > In theory, I think so, but I know that postgres doesn't implement that sort of stuff (check constrints involving other rows/columns/etc), mainly because its slow/not worth it. If you just mean a way of representing the transitions rather than requring the db to ensure that it holds, sure, there are proobably several ways of doing it. In practice, though, I still haven't been convinced that _totally generic customised status transitions/etc are likely to be used by anyone. A smaller subset (say, adding an extra state between two others) is probably going to be more useful. There wil still be hard coded statues, such as UNCONFIRMED, NEW, etc, or, rather, hard coded ids (the names could be changable, in theory) Bradley From gerv at mozilla.org Sat Sep 14 06:35:11 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 14 Sep 2002 07:35:11 +0100 Subject: Configurable Access On Value Transitions? References: <1031897935.28178.162.camel@megagerbil> <3D82251D.40207@mozilla.org> <1031970797.28176.192.camel@megagerbil> Message-ID: <3D82D89F.6050707@mozilla.org> > Like I said, you only need to sacrifice performance if it's actually > used. Long term, we could do something like bug # Number...? :-) >>if ($field eq "foo" && >> $from = "somevalue" && >> $to = "someothervalue" && >> !UserInGroup("somegroup") >>{ >> reject = 1; >>} > > > It is _way_ too much to ask administrators to become Perl hackers in > order to satisfy such a major, needed feature as per-field access > policies. For per-transition policies, maybe it isn't. You keep saying it's needed - who's asking for it? From the comments I've seen in the newsgroups, most sites have a policy which is very simple - just a bit different from the default. For example: "unless you are logged in, you can't add a comment", or "you need to be in the QA group to change the severity". Such things can be managed as I outline. I really think that this is the 90% solution. Gerv From gerv at mozilla.org Sat Sep 14 06:38:05 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 14 Sep 2002 07:38:05 +0100 Subject: 2.18 Goals References: <1031815594.20860.188.camel@megagerbil> <3D808638.90801@mozilla.org> <1031839539.20864.206.camel@megagerbil> <3D822731.6080204@mozilla.org> <1031970985.28180.196.camel@megagerbil> Message-ID: <3D82D94D.2070001@mozilla.org> MattyT wrote: > On Sat, 2002-09-14 at 03:28, Gervase Markham wrote: >>Query URLs could start containing IDs instead of names, if that would >>help. > > That's possible, but makes it really hard to roll your own. > >>But I don't know why you want them expunged - they certainly >>aren't going away, because they are far too useful for users (bookmarks, >>emails etc.) > > The current implementation needs to go away - we need to store IDs in > the database for stored queries and so on. But what about bookmarks? Loads of people have bookmarked queries. There are two possible solutions: - don't rename resolutions or statuses on a running Bugzilla. - allow both IDs and names in query URLs (i.e. names cannot be numeric) We have to store queries in the database as URLs because people want to be able to edit them, and SQL2URL is a very hard problem. >>That's a bit specific; a lot of installations don't have a URL field at >>all. I'd question whether it needs to be part of the default set. >>... >>This is rather a fine distinction. Can't we find a non-insulting name >>which covers both for the default set? > > That's up to an administrator to decide ... these are demonstrating > possibilities, not the final resolutions, and I don't think they are > doing a bad job of that. No, it's the default set. It's up to us to decide what we want the default set to be. I anticipate a load of user questions asking the difference; how the default set works should be obvious. Gerv From matty at chariot.net.au Sat Sep 14 08:37:12 2002 From: matty at chariot.net.au (MattyT) Date: 14 Sep 2002 18:07:12 +0930 Subject: 2.18 Goals In-Reply-To: References: Message-ID: <1031992645.28178.206.camel@megagerbil> On Sat, 2002-09-14 at 14:07, Bradley Baetz wrote: > If you just mean a way of representing the transitions rather than > requring the db to ensure that it holds, sure, there are proobably several > ways of doing it. How did we get onto transitions? I was referring to storing query URLs as a set of records pointing to the relevant ID. > In practice, though, I still haven't been convinced that _totally generic > customised status transitions/etc are likely to be used by anyone. A > smaller subset (say, adding an extra state between two others) is probably > going to be more useful. There wil still be hard coded statues, such as > UNCONFIRMED, NEW, etc, or, rather, hard coded ids (the names could be > changable, in theory) I have no intention of having "hardcoded" statuses when I customise them. Things such as confirmation, resolution, etc can be represented cleanly by predicates on status records. -- 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 bugreport at peshkin.net Sat Sep 14 23:55:50 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 14 Sep 2002 16:55:50 -0700 Subject: Configurable Access On Value Transitions? References: <1031897935.28178.162.camel@megagerbil> <3D82251D.40207@mozilla.org> <1031970797.28176.192.camel@megagerbil> <3D82D89F.6050707@mozilla.org> Message-ID: <3D83CC86.3020703@peshkin.net> The per-field access permissions would definitely take care of issues like ensuring that only reviewers do review and that certain people can change target milestones,. etc.. If you want to do something where a bug can only be closed by certain people, then some additional rules are needed. If we can find a GOOD way to generalize it, that would be ideal. -Joel From gerv at mozilla.org Sun Sep 15 22:24:20 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 15 Sep 2002 23:24:20 +0100 Subject: Configurable Access On Value Transitions? References: <1031897935.28178.162.camel@megagerbil> <3D82251D.40207@mozilla.org> <3D8226E8.6070601@peshkin.net> Message-ID: <3D850894.2070207@mozilla.org> > Rather than inventing a new language Perl may be a very good language in > which to capture site-specific rules. > If we can ensure that CheckCanChangeField has easy access to sufficient > information and is structured in a manner that causes site-changes not > to generally conflict with BZ update, this is a perfectly good way to go. There is now a patch attached to http://bugzilla.mozilla.org/show_bug.cgi?id=168804 (Document CheckCanChangeField so sites can modify it for local needs) which does what I've been suggesting. As well as changing the code, It includes a new section documenting how it works for the Bugzilla Guide. If people could have a look at what I've done and comment in the bug, that would be great. Irrespective of whether we eventually have a more sophisticated implementation, I believe this is worth doing now. Gerv From bugreport at peshkin.net Mon Sep 16 15:46:46 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 16 Sep 2002 08:46:46 -0700 Subject: Remove "review" keyword from the follwoing list of bugs? Message-ID: <3D85FCE6.7090208@peshkin.net> All: Going through the items with "review" keywords, the following should either have review yanked or be killed altogether... Please scream if you object to yanking the "review" keywords from the following list and changing the status on the ones marked "CLOSE" to RESOLVED-something_insulting. Also, 2 appear to have completed review and are just awaiting checkin. -Joel http://bugzilla.mozilla.org/show_bug.cgi?id=102571 -- last patch has needs-work http://bugzilla.mozilla.org/show_bug.cgi?id=99260 -- looks handy and some work done, but nothing apparrently ready to review http://bugzilla.mozilla.org/show_bug.cgi?id=145965 -- documentation maintainence - anything to review here? http://bugzilla.mozilla.org/show_bug.cgi?id=70710 -- old attachments not done as diff -- nothing to reivew here? http://bugzilla.mozilla.org/show_bug.cgi?id=102681 -- bitrotted & at last word, Jouni suggested this move to contrib -- nothing to review here? http://bugzilla.mozilla.org/show_bug.cgi?id=102691 -- seems to be abandoned http://bugzilla.mozilla.org/show_bug.cgi?id=102852 -- seems to be abandoned http://bugzilla.mozilla.org/show_bug.cgi?id=102942 -- nothing to review -- last seen at needs-work and author not available http://bugzilla.mozilla.org/show_bug.cgi?id=103636 -- patch is submitted for comment only, nothing to review? http://bugzilla.mozilla.org/show_bug.cgi?id=123143 -- last patch has need-work, nothing to review? http://bugzilla.mozilla.org/show_bug.cgi?id=160595 -- last comment is "bad idea" from bbaetz (Aug 1) and no response from author --> nothing to review? (Incidentally, I concurr with the "bad idea" comment) CLOSE http://bugzilla.mozilla.org/show_bug.cgi?id=123454 -- last patch has needs-work in Feb 02. Nothing to review? http://bugzilla.mozilla.org/show_bug.cgi?id=20122 -- last patch has needs-work. Nothing to review ? http://bugzilla.mozilla.org/show_bug.cgi?id=68022 -- nothing current awaiting review http://bugzilla.mozilla.org/show_bug.cgi?id=28357 -- last patch has needs-work. Nothing to review? (2 years stale) CLOSE http://bugzilla.mozilla.org/show_bug.cgi?id=91037-- last patch has needs-work. Nothing to review? http://bugzilla.mozilla.org/show_bug.cgi?id=63601 -- timeless or myk --> ball in your court? looks ready for checkin http://bugzilla.mozilla.org/show_bug.cgi?id=152935 -- reviews were done in june, needs to be merged into HEAD before it rots From gerv at mozilla.org Wed Sep 18 19:10:56 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 18 Sep 2002 20:10:56 +0100 Subject: page.cgi bustage Message-ID: <3D88CFC0.8060404@mozilla.org> Sorry about that; now fixed, hopefully. Gerv From gerv at mozilla.org Wed Sep 18 20:02:29 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 18 Sep 2002 21:02:29 +0100 Subject: PS/PDF guide Message-ID: <3D88DBD5.4040308@mozilla.org> http://bugzilla.mozilla.org/show_bug.cgi?id=169162 Do we have the ability to generate PS or PDF versions of the Bugzilla Guide? The README.docs implies so, but gives no commands, and my guessing hasn't worked. Gerv From mbarnson at sisna.com Wed Sep 18 20:31:30 2002 From: mbarnson at sisna.com (Matthew P. Barnson) Date: Wed, 18 Sep 2002 14:31:30 -0600 Subject: PS/PDF guide References: <3D88DBD5.4040308@mozilla.org> Message-ID: <3D88E2A2.4000008@sisna.com> Gervase Markham wrote: > Do we have the ability to generate PS or PDF versions of the Bugzilla > Guide? The README.docs implies so, but gives no commands, and my > guessing hasn't worked. Sorry to reply twice. The main reason for writing the Guide in Docbook XML in the first reason was so that it could be included in the Linux Documentation Project. I figured (and still do) that if a project is on the Linuxdoc Guides or Howtos list, you'll get wider dissemination and awareness of the project. Anyway, my process for making a file into ps/pdf using mozilla + ps2pdf is flawed. The table of contents, index, and glossary won't match the page numbers, although the formatting would otherwise be OK Here's the real solution, available at linuxdoc: http://www.tldp.org/authors/index.html Down at the bottom of the page, it goes into a little bit of detail on how they do it at Linuxdoc. It appears they use a combination of a custom script, ldp_print, plus the htmldoc utility I mentioned in the previous message. The heading of the passage is "PDF/Postscript Output". At the very least, that's the "official" way Linuxdoc updates it. Alternatively, you can get an updated version by submitting the updated Guide to LDP, and they'll do it for you. Don't try to use their email gateway on The Bugzilla Guide, though, it chokes on the multiple file input. HTH! --Matt Barnson From mbarnson at sisna.com Wed Sep 18 20:17:15 2002 From: mbarnson at sisna.com (Matthew P. Barnson) Date: Wed, 18 Sep 2002 14:17:15 -0600 Subject: PS/PDF guide References: <3D88DBD5.4040308@mozilla.org> Message-ID: <3D88DF4B.8080209@sisna.com> Gervase Markham wrote: > http://bugzilla.mozilla.org/show_bug.cgi?id=169162 > > Do we have the ability to generate PS or PDF versions of the Bugzilla > Guide? The README.docs implies so, but gives no commands, and my > guessing hasn't worked. > > Gerv There is no direct conversion for Docbook XML to PS/PDF. However, there are several indirect ways to approach this problem: 1. Use a tool such as "HTMLDOC" to convert to PDF after rendering to HTML 2. Use "a2ps", another common utility, to convert to postscript from the text version of the Guide created by Lynx. Warning, though, this results in very ugly, plain-text-ish output. Lots of different options for the conversion, though. a2ps is an invaluable utility. 3. Load the HTML Guide up in Mozilla on a GNU/Linux machine, and print it to a file. The file will be .ps, which you can then use ps2pdf on to create PDF. Option 3 is the easiest, and the one I use when I want a PDF most times. I'm not terrifically familiar with HTMLDOC, nor other html to ps conversion tools. The unfortunate thing is that it's not necessarily a portable option for PS or PDF creation. The nice thing is, though, on a GNU/Linux system, all you need is Mozilla & Ghostscript and you are in business. The ghostscript package on my Redhat 7.3 system at work is labelled "ghostscript-6.52-8". Hope that helps, Gerv! After a lot of thinking, batting the idea around, and saying I want to do more and then not doing it, I'm pretty certain I won't be much into Bugzilla again until/unless I'm using it in a corporate setting, but I'm always happy to help :) Emails to "matthew at barnson.org" will be promptly answered! --Matt Barnson From gerv at mozilla.org Wed Sep 18 22:33:28 2002 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 18 Sep 2002 23:33:28 +0100 Subject: $::vars hash Message-ID: <3D88FF38.4050701@mozilla.org> As you will know, the current templatisation system uses a $::vars global variable to pass variables to the template. What you may not know is that some variables get stashed in it for you, meaning you don't need to stash them again. Here's the current list: There are the following functions: $vars->{'Param'} - for retrieving global parameters $vars->{'lsearch'} - Generic search function to find items in arrays $vars->{'UserInGroup'} - for seeing if a user is in a group $vars->{'time2str'} - for creating date strings. For l10n reasons, please use. And the following strings: $vars->{'user_agent'} - the user's user-agent; useful for the occasional fork $vars->{'VERSION'} - the Bugzilla version There's a $vars->{'user'} object: $user{'login'} - the user's login name (email address) $user{'userid'} - the user's numeric userid Other info from user record: $user{'showmybugslink'} $user{'realname'} - real name $user{'groupset'} $user{'blessgroupset'} $user{'queries'} is a list of hashes of info about the user's saved queries. $user{'groups'} is a hash, keyed by name, of group bits. These items are accessed as $vars->{'user'}{'realname'}, or [% user.realname %] in the templates. If you have other information to pass into a template which relates to the user, please store it in the user object. Gerv From bbaetz at student.usyd.edu.au Wed Sep 18 23:12:50 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 19 Sep 2002 09:12:50 +1000 (EST) Subject: $::vars hash In-Reply-To: <3D88FF38.4050701@mozilla.org> References: <3D88FF38.4050701@mozilla.org> Message-ID: What you also may not know is that global variables suck, and that the global version hash will be removed at some point :) Please avoid adding any more page-specific variables to this global hash Functions, and semi-constants like VERSION are ok; stuff like $vars->{'header_done'} isn't. The reason for this is that this affects mod_perl'isation, with the gloabl var and so on. Bradley From myk at mozilla.org Wed Sep 18 23:16:21 2002 From: myk at mozilla.org (Myk Melez) Date: Wed, 18 Sep 2002 16:16:21 -0700 Subject: $::vars hash References: <3D88FF38.4050701@mozilla.org> Message-ID: <3D890945.6050602@mozilla.org> Gervase Markham wrote: > There's a $vars->{'user'} object: > These items are accessed as $vars->{'user'}{'realname'}, or [% > user.realname %] in the templates. Note that work going in bugs 98801 and 162990 will likely change the structure of this object at some point, so stay alert to those changes. http://bugzilla.mozilla.org/show_bug.cgi?id=98801 http://bugzilla.mozilla.org/show_bug.cgi?id=162990 -myk From gerv at mozilla.org Wed Sep 18 23:19:06 2002 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 19 Sep 2002 00:19:06 +0100 Subject: $::vars hash References: <3D88FF38.4050701@mozilla.org> Message-ID: <3D8909EA.1010707@mozilla.org> Bradley Baetz wrote: > What you also may not know is that global variables suck, and that the > global version hash will be removed at some point :) But in the mean time, you shouldn't reinvent the wheel by re-adding this data to it in your CGIs. > The reason for this is that this affects mod_perl'isation, with the gloabl > var and so on. Global variables are OK in mod_perl if they get emptied at the beginning of each execution, right? So surely, if all our global variables are part of $vars, that means we only have to empty/nullify one variable :-) Gerv From bbaetz at student.usyd.edu.au Wed Sep 18 23:26:22 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Thu, 19 Sep 2002 09:26:22 +1000 (EST) Subject: $::vars hash In-Reply-To: <3D8909EA.1010707@mozilla.org> Message-ID: On Thu, 19 Sep 2002, Gervase Markham wrote: > Bradley Baetz wrote: > > What you also may not know is that global variables suck, and that the > > global version hash will be removed at some point :) > > But in the mean time, you shouldn't reinvent the wheel by re-adding this > data to it in your CGIs. Right, but if you add more stuff, expect be to be annoyed, mainly because it usually means a resdesign to fix... > > > The reason for this is that this affects mod_perl'isation, with the gloabl > > var and so on. > > Global variables are OK in mod_perl if they get emptied at the beginning > of each execution, right? So surely, if all our global variables are > part of $vars, that means we only have to empty/nullify one variable :-) Sure. Where do you do that? Remember, the |require globals.pl| won't be run on every request.... (Yes, you can register a cleanup hook for mod_perl, and reset it there. Lets just not go there.) Bradley From gerv at mozilla.org Sat Sep 21 12:50:23 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 21 Sep 2002 13:50:23 +0100 Subject: Admin interface - browser requirement Message-ID: <3D8C6B0F.4080501@mozilla.org> It's long been Bugzilla's policy to support as many browsers as possible on the standard user interface - down to, and including, Lynx. (Not sure how well we work on Netscape 3, though.) We also never require JavaScript. However, do we need to be as accommodating for the admin pages? For example, sortkeys. The best UI for setting these would be a multi-select list of items with buttons which triggered JavaScript to move items up and down, and then create a form submission which reflected the new order. But such JS and DOM could really only be made to work (without a lot of headaches) in modern browsers (IE 5.5+, Mozilla/Netscape6+, perhaps Konqueror.) Is it reasonable to trade off, on the admin interface _only_, the ability to support lots of old browsers against the ability to have a more usable UI? Gerv From kiko at async.com.br Sat Sep 21 13:27:22 2002 From: kiko at async.com.br (Christian Reis) Date: Sat, 21 Sep 2002 10:27:22 -0300 Subject: Admin interface - browser requirement In-Reply-To: <3D8C6B0F.4080501@mozilla.org>; from gerv@mozilla.org on Sat, Sep 21, 2002 at 01:50:23PM +0100 References: <3D8C6B0F.4080501@mozilla.org> Message-ID: <20020921102722.A507@blackjesus.async.com.br> On Sat, Sep 21, 2002 at 01:50:23PM +0100, Gervase Markham wrote: > However, do we need to be as accommodating for the admin pages? For > example, sortkeys. The best UI for setting these would be a multi-select > list of items with buttons which triggered JavaScript to move items up > and down, and then create a form submission which reflected the new > order. But such JS and DOM could really only be made to work (without a > lot of headaches) in modern browsers (IE 5.5+, Mozilla/Netscape6+, > perhaps Konqueror.) One other possibility would be to use an HTML TABLE with "up" and "down" buttons, though accessibility-wise the labels do suffer a bit. Javascript could, in this case, as a shortcut to allow moving the items without reloading the page, and it's fairly easy to do the non-JS form submission by checking on button pressed. 1. Bugzilla (^ up ) (v down) 2. NSPR (^ up ) (v down) 3. Calendar (^ up ) (v down) 4. Browser (^ up ) (v down) 5. CCK (^ up ) (v down) I would rather not loose support for Lynx editing products, and I don't think its a reasonable trade off. For large numbers of products (I'd say over 20), editing the sortkeys directly in an advanced interface should also be considered. 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 Sat Sep 21 13:57:05 2002 From: myk at mozilla.org (Myk Melez) Date: Sat, 21 Sep 2002 06:57:05 -0700 Subject: Admin interface - browser requirement References: <3D8C6B0F.4080501@mozilla.org> Message-ID: <3D8C7AB1.8010807@mozilla.org> Gervase Markham wrote: > But such JS and DOM could really only be made to work (without a lot > of headaches) in modern browsers (IE 5.5+, Mozilla/Netscape6+, perhaps > Konqueror.) Actually NS and IE 4.x had pretty good support for this kind of interface, albeit via unpalatable DOM-0 method calls. > Is it reasonable to trade off, on the admin interface _only_, the > ability to support lots of old browsers against the ability to have a > more usable UI? It's certainly much more reasonable than confining the vast majority of our administrators to the clunky UI supported by browsers only a small minority of our administrators use. Note that you can support both, however, by making the list reordering buttons submit to the server on non-JavaScript browsers and reordering server-side. It's clunky, but it does provide the necessary functionality. On the other hand, we could just make 'em use SQL. -myk From kiko at async.com.br Sat Sep 21 14:32:44 2002 From: kiko at async.com.br (Christian Reis) Date: Sat, 21 Sep 2002 11:32:44 -0300 Subject: Admin interface - browser requirement In-Reply-To: <3D8C7AB1.8010807@mozilla.org>; from myk@mozilla.org on Sat, Sep 21, 2002 at 06:57:05AM -0700 References: <3D8C6B0F.4080501@mozilla.org> <3D8C7AB1.8010807@mozilla.org> Message-ID: <20020921113244.B507@blackjesus.async.com.br> On Sat, Sep 21, 2002 at 06:57:05AM -0700, Myk Melez wrote: > > Is it reasonable to trade off, on the admin interface _only_, the > > ability to support lots of old browsers against the ability to have a > > more usable UI? > > It's certainly much more reasonable than confining the vast majority of > our administrators to the clunky UI supported by browsers only a small > minority of our administrators use. I thought a bit about this, and my proposal for UI is a bad one. I withdraw it and put a paper bag on my head. The main problem with it is the non-scrolling of the HTML table which makes the buttons change position, and that would suck. However, I still don't think we should abandon lynx and other text-browsers. > Note that you can support both, however, by making the list reordering > buttons submit to the server on non-JavaScript browsers and reordering > server-side. It's clunky, but it does provide the necessary > functionality. On the other hand, we could just make 'em use SQL. Yeah, we could make it server-side, as a fallback. Sounds good. Hacking SQL is quite an evil alternative; I think a compat interface that allowed editing sortkeys directly isn't too evil an idea. It does fork the UI on the functionality, though. 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 Sun Sep 22 17:43:30 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Sun, 22 Sep 2002 10:43:30 -0700 Subject: Groups system has landed Message-ID: <3D8E0142.7090307@peshkin.net> All: The major change to the group system (bugs 157756 and 68022) has landed in the CVS HEAD (a.k.a 2.17). This is the most dramatic schema change that Bugzilla has seen since I have been involved and the same is probably true for most of you. Even though this has been carefully reviewed and has been tested, I cannot stress enough the importance of confirming that you have a working capability to restore your database to the pre-update state before you update. There is one known regression at this time, bug 170195, but it only effects highlighting of buglists. For those of you who have good test capabilities, please beat this up and CC me on any new bugs that result from it. I will aggressively jump on any regressions. Thanks to all the reviewers and testers who stayed on the case on this one. -Joel From gerv at mozilla.org Tue Sep 24 22:56:44 2002 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 24 Sep 2002 23:56:44 +0100 Subject: Graph module design Message-ID: <3D90EDAC.3030609@mozilla.org> I've done a rough design (UI and otherwise) for the new "generic graphing" module for Bugzilla. Please take a look and say what you think in the newsgroup. http://www.mozilla.org.uk/temp/graph/ Gerv From bugreport at peshkin.net Tue Sep 24 23:12:39 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 24 Sep 2002 16:12:39 -0700 Subject: Graph module design References: <3D90EDAC.3030609@mozilla.org> Message-ID: <3D90F167.4050702@peshkin.net> Terminology: Sounds OK Who gets to define datasets and how far do they get shared? Now that we have an arbitrary number of groups available, it should be possible to designate a group of users who are permitted to create datasets where those datasets are "owned" by the user who created them but can be shared with others in a manner similar to the way a bug can be shared with others or restricted. Ideally, it should be possible to create a group of datasets in a single action. For example, I may like to have the REOPENED bugs in productA or productB at a priority of 1 and the same query at a priority of 2, 3, 4, and 5. Ideally, I should be able to specify a dataset for the REOPENED bugs in productA or productB GROUPED BY priority. Don't forget to make it easy to get the data in some form like CSV. I would still like to see retroactive generation of these graphs be possible, though bug 163463 should be addressed if we do this. (This could be limited to certain fields that can be retroactively figured out rather than rolling everything back) -Joel From myk at mozilla.org Fri Sep 27 16:54:10 2002 From: myk at mozilla.org (Myk Melez) Date: Fri, 27 Sep 2002 09:54:10 -0700 Subject: corporate win--their requirements Message-ID: <3D948D32.1020509@mozilla.org> A large corporation that I'll call Zippy has decided to adopt Bugzilla to track defects in its software products across a large development division with several thousand employees. This is a big win for Bugzilla, not to mention Zippy. It also means Zippy will be doing a lot of Bugzilla work in the near future to make our application meet its needs. I want to make sure Zippy contributes their changes back to Bugzilla and that our future development takes their needs into account. To that end, I'll be analyzing their requirements and translating them into generally-useful feature requests or comments/design suggestions on existing feature requests. Here is a partial list of issues I've identified and what I know about them so far. Please take a look and let me know your thoughts. Product and User Views Different products may have different bug tracking needs, especially when they are being worked on by separate teams, so it should be possible to customize the "enter bug" and "show bug" UIs (showing/hiding various fields) based on the product to which a bug belongs. Different types of users (development, QA, project management, etc.) also have very different needs and interests, so it should be possible to customize the UIs for each of these groups. Sybase Support Bugzilla should support Sybase. Zippy has already done most of the work for this, although maybe in a hacky fashion. We should have a clear idea about how customers should add multi-database support so people don't waste their time and ours doing it the wrong way. Custom fields It should be possible for the Bugzilla administrator to define custom fields in addition to the built-in fields. Custom fields should be product-specific. Third Level of Categorization (sub-component) It would be useful to have a third level of categorization in addition to product and component. Custom Resolutions It should be possible to define the resolutions available to bugs on a product-specific basis. Reopened Count It would be useful to know how many times a bug has been reopened without having to count rows on the bug activity page. This could appear right next to the status of reopened bugs. Pull-down Menu of Assignees It should be possible to select assignees from a list instead of having to type in their full email addresses. Time Zone-sensitive Date/Time Display Dates and times should be displayed in the user's time zone, not the server's time zone. Entry of International Data It should be possible to enter non-ASCII data into Bugzilla. Project Management Fields There should be fields in Bugzilla for tracking project status, f.e. hours required to fix a bug, estimated fix date, etc. System Configuration Fields There should be fields in Bugzilla for more specifically identifying reporters' system configurations (CPU, memory, etc.). From gerv at mozilla.org Fri Sep 27 21:11:54 2002 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 27 Sep 2002 22:11:54 +0100 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> Message-ID: <3D94C99A.8000304@mozilla.org> Myk Melez wrote: > A large corporation that I'll call Zippy has decided to adopt Bugzilla > to track defects in its software products across a large development > division with several thousand employees. Fantastic :-) Looking at this list, I think that the Bugzilla development team would do well to let Zippy's requirements set the agenda for development for a period - this will benefit both us and Zippy in the long run. What sort of timeframe is Zippy looking at to get all these enhancements made? This list looks like a fair amount of work - and some of it has dependencies. For example, we can't do custom resolutions without generic graphing, which is a fairly big hunk of code. > Product and User Views > > Different products may have different bug tracking needs, especially > when they are being worked on by separate teams, so it should be > possible to customize the "enter bug" and "show bug" UIs (showing/hiding > various fields) based on the product to which a bug belongs. Different > types of users (development, QA, project management, etc.) also have > very different needs and interests, so it should be possible to > customize the UIs for each of these groups. Does this require some sort of explicit support, or can this be done by Zippy replacing e.g. search.html.tmpl with a custom "distributor" template which analyses the requirements for that CGI/user/product and then PROCESSes the appropriate custom template? > Sybase Support > > Bugzilla should support Sybase. Zippy has already done most of the work > for this, although maybe in a hacky fashion. We should have a clear > idea about how customers should add multi-database support so people > don't waste their time and ours doing it the wrong way. This is bbaetz territory. But we should try our hardest to do this in terms of generic database support, rather than "MySQL and Sybase". > Custom fields > > It should be possible for the Bugzilla administrator to define custom > fields in addition to the built-in fields. Custom fields should be > product-specific. Is anyone on this list responsible for the current custom fields patch, or are we going to have to find a core developer to shepherd it into the tree (as MattyT suggested)? > Third Level of Categorization (sub-component) > > It would be useful to have a third level of categorization in addition > to product and component. My company's (inferior, home-grown) bug tracker uses this also - it's one of the key schema differences. It does add some complexities, though - particularly in moving bugs between products and components (more "adjust these fields" pages), and you get a large amount of JS on the query.cgi page because it has to carry the names of every product, component and sub-component. I was struggling with this problem the other day for custom graphing. Is there any way of getting JS to update form fields with values fetched from a server, in a way that even works in Netscape 4? Will this mean starting to require JS on pages like the search page? > Custom Resolutions > > It should be possible to define the resolutions available to bugs on a > product-specific basis. Sidenote: I think we should be making the Product the configuration barrier for a lot of things. Combined with the third level of categorisation, we can start to make a lot of settings product-specific. > Reopened Count > > It would be useful to know how many times a bug has been reopened > without having to count rows on the bug activity page. This could > appear right next to the status of reopened bugs. This seems like a fairly simple RFE. Would it only have to appear when the bug was in the REOPENED state, or would it also appear in the ASSIGNED state? > Pull-down Menu of Assignees > > It should be possible to select assignees from a list instead of having > to type in their full email addresses. This is a FRFE. We should do it by using a template to define the UI for user selection wherever it occurs, and making that template do all the work. Would the list be a global list of Bugzilla users, or restricted in some way? > Time Zone-sensitive Date/Time Display > > Dates and times should be displayed in the user's time zone, not the > server's time zone. As far as I can see, this could only be done by having a user pref for timezone. Web browsers don't send this info in a request. But this isn't a particularly complex RFE. We need to centralise date and time formatting anyway, for l10n reasons. > Entry of International Data > > It should be possible to enter non-ASCII data into Bugzilla. It is possible at the moment - as long as we use no charset, and rely on browsers making intelligent guesses. The only other alternative is making charset a parameter. But we need to test with charsets like UTF8. This has been discussed before - what are the issues here? > Project Management Fields > > There should be fields in Bugzilla for tracking project status, f.e. > hours required to fix a bug, estimated fix date, etc. Can you be more specific about exactly which fields are required? There's a patch for this, I know. Can we implement this in terms of custom fields, or does there need to be an interdependence between these fields? > System Configuration Fields > > There should be fields in Bugzilla for more specifically identifying > reporters' system configurations (CPU, memory, etc.). Can we not support this request using enter_bug.cgi comment-formatting templates? Or do they want to query efficiently for all bugs filed by anyone using a Pentium IV processor? Gerv From bugreport at peshkin.net Fri Sep 27 23:17:11 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 27 Sep 2002 16:17:11 -0700 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> Message-ID: <3D94E6F7.3050803@peshkin.net> Gervase Markham wrote: > > >> Pull-down Menu of Assignees >> >> It should be possible to select assignees from a list instead of >> having to type in their full email addresses. > > > This is a FRFE. We should do it by using a template to define the UI > for user selection wherever it occurs, and making that template do all > the work. > > Would the list be a global list of Bugzilla users, or restricted in > some way? > Actually, having tried out drop-down lists on a site with a few hundred users, I suspect that the right approach is in http://bugzilla.mozilla.org/show_bug.cgi?id=162990 coupled with http://bugzilla.mozilla.org/show_bug.cgi?id=145499#c4. This would be a good thing to ask Zippy about. I suspect that they have the same requirement. As far as the issue of restricting the pattern match so that not all users can spot each other by pattern match, I had presumed that this was more of a localization for my site. Is this something of more general interest? -Joel From bbaetz at student.usyd.edu.au Sat Sep 28 01:26:13 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sat, 28 Sep 2002 11:26:13 +1000 (EST) Subject: corporate win--their requirements In-Reply-To: <3D948D32.1020509@mozilla.org> Message-ID: On Fri, 27 Sep 2002, Myk Melez wrote: > Product and User Views > > Different products may have different bug tracking needs, especially > when they are being worked on by separate teams, so it should be > possible to customize the "enter bug" and "show bug" UIs (showing/hiding > various fields) based on the product to which a bug belongs. Different > types of users (development, QA, project management, etc.) also have > very different needs and interests, so it should be possible to > customize the UIs for each of these groups. > product views could just be treated as a 'format', or something. > > Sybase Support > > Bugzilla should support Sybase. Zippy has already done most of the work > for this, although maybe in a hacky fashion. We should have a clear > idea about how customers should add multi-database support so people > don't waste their time and ours doing it the wrong way. At the moment, the answer is 'with great difficultly'. Thats not going to change for a while, though. > Third Level of Categorization (sub-component) > > It would be useful to have a third level of categorization in addition > to product and component. If someone can come up with a UI, I'd prefer 'infinite level'. Since all components are unique ids anyway, if you kow the component, then you know the component's parent, and so on. > Reopened Count > > It would be useful to know how many times a bug has been reopened > without having to count rows on the bug activity page. This could > appear right next to the status of reopened bugs. Eww. Why? > Time Zone-sensitive Date/Time Display > > Dates and times should be displayed in the user's time zone, not the > server's time zone. That requires knowing hte user's timezeon, but yeah, I'd like that. > > Entry of International Data > > It should be possible to enter non-ASCII data into Bugzilla. Well, thats easy, we can do that now. IF you meant that you want to be able to read the results..... This really means for them perl 5.8, and for us adding hooks, probably meaning that the minimum requirement will end up being perl 5.6. > System Configuration Fields > > There should be fields in Bugzilla for more specifically identifying > reporters' system configurations (CPU, memory, etc.). That should just be another custom field, I think. Bradley From myk at mozilla.org Sat Sep 28 02:32:15 2002 From: myk at mozilla.org (Myk Melez) Date: Fri, 27 Sep 2002 19:32:15 -0700 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> Message-ID: <3D9514AF.4080103@mozilla.org> 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. >> Product and User Views > > > Does this require some sort of explicit support, or can this be done > by Zippy replacing e.g. search.html.tmpl with a custom "distributor" > template which analyses the requirements for that CGI/user/product and > then PROCESSes the appropriate custom template? There's two issues here: how to do it and whether to make it custom or check it in. As to the first, a distributor template might work, although we have to come up with a better way to define views than the filename hacks we're doing for formats since views are multi-dimensional (in other words, we don't want to have search-developer-Browser.html.tmpl, search-developer-MailNews.html.tmpl, search-qa-Browser.html.tmpl, etc.). Maybe TT's "views" feature can help us here. As to the second issue, I don't see why this should be custom to their installation. Wanting to customize the interface by product and major user type seems like a feature a lot of installations would find useful. "show bug" is overcrowded as it is, and new fields keep pouring in; chopping it up into targeted pages (with an option to see everything if you want) is something I think b.m.o would also be interested in. > I was struggling with this problem the other day for custom graphing. > Is there any way of getting JS to update form fields with values > fetched from a server, in a way that even works in Netscape 4? It's hard to the point of not being worth it. >> Custom Resolutions > > > Sidenote: I think we should be making the Product the configuration > barrier for a lot of things. Combined with the third level of > categorisation, we can start to make a lot of settings product-specific. Agreed. http://bugzilla.mozilla.org/show_bug.cgi?id=106592 The request tracker's implementation, with inclusions and exclusions lists, is a good start. http://bugzilla.mozilla.org/show_bug.cgi?id=98801 >> Reopened Count > > > This seems like a fairly simple RFE. Would it only have to appear when > the bug was in the REOPENED state, or would it also appear in the > ASSIGNED state? To be really useful I think the latter. >> Pull-down Menu of Assignees > > > This is a FRFE. We should do it by using a template to define the UI > for user selection wherever it occurs, and making that template do all > the work. What's an FRFE? > Would the list be a global list of Bugzilla users, or restricted in > some way? The latter. Probably it would be a list specific to a product and maybe also component. >> Project Management Fields > > > Can you be more specific about exactly which fields are required? > There's a patch for this, I know. Can we implement this in terms of > custom fields, or does there need to be an interdependence between > these fields? I'm not sure what the logic of these fields needs to be, but I suspect it'll be more than custom fields can handle. I'll try to find out more about it. >> System Configuration Fields > > > Can we not support this request using enter_bug.cgi comment-formatting > templates? Or do they want to query efficiently for all bugs filed by > anyone using a Pentium IV processor? The latter. -myk From myk at mozilla.org Sat Sep 28 02:39:09 2002 From: myk at mozilla.org (Myk Melez) Date: Fri, 27 Sep 2002 19:39:09 -0700 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> <3D94E6F7.3050803@peshkin.net> Message-ID: <3D95164D.8020309@mozilla.org> Joel Peshkin wrote: > Actually, having tried out drop-down lists on a site with a few > hundred users, I suspect that the right approach is in > http://bugzilla.mozilla.org/show_bug.cgi?id=162990 coupled with > http://bugzilla.mozilla.org/show_bug.cgi?id=145499#c4. 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. > This would be a good thing to ask Zippy about. I suspect that they > have the same requirement. I'll point it out. -myk From justdave at syndicomm.com Sat Sep 28 03:12:39 2002 From: justdave at syndicomm.com (David Miller) Date: Fri, 27 Sep 2002 23:12:39 -0400 Subject: corporate win--their requirements In-Reply-To: <3D948D32.1020509@mozilla.org> References: <3D948D32.1020509@mozilla.org> Message-ID: On 9/27/02 9:54 AM -0700, Myk Melez wrote: > Product and User Views > > Different products may have different bug tracking needs, especially > when they are being worked on by separate teams, so it should be > possible to customize the "enter bug" and "show bug" UIs (showing/hiding > various fields) based on the product to which a bug belongs. Different > types of users (development, QA, project management, etc.) also have > very different needs and interests, so it should be possible to > customize the UIs for each of these groups. This should be not-too-incredibly-difficult with the existing template system. Just put conditional blocks in the template based on which product is being accessed. On the other hand, that could get busy fast. > Sybase Support > > Bugzilla should support Sybase. Zippy has already done most of the work > for this, although maybe in a hacky fashion. We should have a clear > idea about how customers should add multi-database support so people > don't waste their time and ours doing it the wrong way. We've learned a lot from the Postgres experience, which is going to be landing soon I'm told. :-) Don't know how different that is to Sybase though... I've dealt enough with Oracle now I could probably pull off making it work with Oracle again. Multiple database support would be a good thing. > Third Level of Categorization (sub-component) > > It would be useful to have a third level of categorization in addition > to product and component. I'd go for the infinite levels myself (or at least multiple), where everything except the top-level "product" has a parent component. > Pull-down Menu of Assignees > > It should be possible to select assignees from a list instead of having > to type in their full email addresses. There's a few ways of doing this... if you have lots of people, one of the Javascript pickers might be good to have. I've actually been playing around a bit with the picker concept for a different project at work, and if you clean it up a bit, it's not as bad as it sounds :) > Time Zone-sensitive Date/Time Display > > Dates and times should be displayed in the user's time zone, not the > server's time zone. If they have Javascript active, we can know their timezone the first time they submit a form (i.e. at create-account). If they don't, we assume the timezone of the local server, until the user changes their preferences to say otherwise. > System Configuration Fields > > There should be fields in Bugzilla for more specifically identifying > reporters' system configurations (CPU, memory, etc.). This could in theory be done with custom fields. Although that's a generic enough thing that would be generally useful in a lot of places, so they probably should be dedicated fields with a preference whether to use them or not. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From caillon at returnzero.com Sat Sep 28 03:58:01 2002 From: caillon at returnzero.com (Christopher A. Aillon) Date: Fri, 27 Sep 2002 21:58:01 -0600 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> Message-ID: <3D9528C9.1090301@returnzero.com> David Miller wrote: >>Time Zone-sensitive Date/Time Display >> >>Dates and times should be displayed in the user's time zone, not the >>server's time zone. > > > If they have Javascript active, we can know their timezone the first time > they submit a form (i.e. at create-account). If they don't, we assume the > timezone of the local server, until the user changes their preferences to > say otherwise. Yes. Or you could just use JS to call Date.getTimezoneOffset(). From justdave at syndicomm.com Sat Sep 28 03:52:51 2002 From: justdave at syndicomm.com (David Miller) Date: Fri, 27 Sep 2002 23:52:51 -0400 Subject: corporate win--their requirements In-Reply-To: <3D9528C9.1090301@returnzero.com> References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> Message-ID: On 9/27/02 9:58 PM -0600, Christopher A. Aillon wrote: > David Miller wrote: >>>Time Zone-sensitive Date/Time Display >>> >>>Dates and times should be displayed in the user's time zone, not the >>>server's time zone. >> >> >> If they have Javascript active, we can know their timezone the first time >> they submit a form (i.e. at create-account). If they don't, we assume the >> timezone of the local server, until the user changes their preferences to >> say otherwise. > > > Yes. Or you could just use JS to call Date.getTimezoneOffset(). Isn't that what I just said? :-) -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From caillon at returnzero.com Sat Sep 28 04:16:38 2002 From: caillon at returnzero.com (Christopher A. Aillon) Date: Fri, 27 Sep 2002 22:16:38 -0600 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> Message-ID: <3D952D26.3010105@returnzero.com> Ok so let me clarify. justdave's intent (AIUI) was to store this in the database after submitting with a form. My intent is that we should not store this stuff in the db. Just rely on the client to do it. Write JS that adjusts the times by the offset if necessary. I travel in between timezones and want this to just work without me fiddling around in preferences. I don't want to be in NY and see the time in CA. From justdave at syndicomm.com Sat Sep 28 04:14:09 2002 From: justdave at syndicomm.com (David Miller) Date: Sat, 28 Sep 2002 00:14:09 -0400 Subject: corporate win--their requirements In-Reply-To: <3D952D26.3010105@returnzero.com> References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> <3D952D26.3010105@returnzero.com> Message-ID: On 9/27/02 10:16 PM -0600, Christopher A. Aillon wrote: > Ok so let me clarify. justdave's intent (AIUI) was to store this in the > database after submitting with a form. My intent is that we should not store > this stuff in the db. Just rely on the client to do it. Write JS that >adjusts > the times by the offset if necessary. I travel in between timezones and want > this to just work without me fiddling around in preferences. I don't >want to be > in NY and see the time in CA. Ah, yeah, but then it always depends on the user having Javascript anyway... not to mention we wind up having to find creative ways to name and display the time elements so the Javascript can alter them. (Can you access the .text property of a ?) -- Dave Miller Project Leader, Bugzilla Bug Tracking System Lead Software Engineer/System Administrator, Syndicomm Online http://www.syndicomm.com/ http://www.bugzilla.org/ From burnus at gmx.de Fri Sep 27 17:56:40 2002 From: burnus at gmx.de (Tobias Burnus) Date: Fri, 27 Sep 2002 19:56:40 +0200 Subject: [Bugzilla] RFC: /usr/bonsaitools/bin/perl -> /usr/bin/perl ? Message-ID: <3D949BD8.3CC5D60F@gmx.de> Hi, how about -#!/usr/bonsaitools/bin/perl -wT +#!/usr/bin/perl -wT for Bugzilla? I believe the vast majority of bugzilla users uses /usr/bin/perl and on 99% of the unix systems it lies there. Using a perl at a different location is rather the exception than the rule and /usr/local/bin/perl is probably more spread. This removes the tons of M relogin.cgi when doing a cvs update while on b.m.o it wouldn't harm since the Bugzilla is anyway modified to a greater extend. There is yet another posibility which solves /usr/bin vs. /usr/local/bin: eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}' && eval 'exec perl -S $0 $ argv:q' if 0; based on the path instead of using a hard coded perl. But this is probably not the best solution for a webserver. Tobias -- This above all: To thine own self be true / And it must follow as the night the day / Thou canst not then be false to any man. From preed at sigkill.com Sat Sep 28 04:43:16 2002 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 27 Sep 2002 21:43:16 -0700 (PDT) Subject: [Bugzilla] RFC: /usr/bonsaitools/bin/perl -> /usr/bin/perl ? In-Reply-To: <3D949BD8.3CC5D60F@gmx.de> Message-ID: On Fri, 27 Sep 2002, Tobias Burnus wrote: > how about > -#!/usr/bonsaitools/bin/perl -wT > +#!/usr/bin/perl -wT > > for Bugzilla? See bug 44202 "Easily replace /usr/bonsaitools/bin/perl with your perl path" which is a dup of bug 44659 "[meta] Makefile may help install, quiz program?" 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 bbaetz at student.usyd.edu.au Sat Sep 28 05:06:42 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sat, 28 Sep 2002 15:06:42 +1000 (EST) Subject: [Bugzilla] RFC: /usr/bonsaitools/bin/perl -> /usr/bin/perl ? In-Reply-To: <3D949BD8.3CC5D60F@gmx.de> Message-ID: zach was going to take care of this during his install rewrite, but that hasn't happened yet. I really do think we should do this - lets let bmo change, if they want something different (Do they anymore, anyway, since bm ois now its own amachine?) The path will be ignored for installations running under mod_perl, anyway. Bradley From caillon at returnzero.com Sat Sep 28 05:18:09 2002 From: caillon at returnzero.com (Christopher A. Aillon) Date: Fri, 27 Sep 2002 23:18:09 -0600 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> <3D952D26.3010105@returnzero.com> Message-ID: <3D953B91.4030901@returnzero.com> David Miller wrote: > Ah, yeah, but then it always depends on the user having Javascript > anyway... not to mention we wind up having to find creative ways to name > and display the time elements so the Javascript can alter them. (Can you > access the .text property of a ?) JS is generally used for enhancing a site. If a user doesn't want it on, that's fine, they can use Bugzilla without it without any loss of functionality. This is an enhancement though and the people that typically care about this sort of thing are end users who do have JS on. This is a client related thing and we shouldn't do client things on the server side. Plus I bet there is some interest in keeping the DB size down. Anyway, get a reference to the span element and there are various ways to get at its text. Probably using .innerText or .innerHTML is the easiest. Though non-standardized, it's an extension that MS and we support. If you want it to use DOM standards, then use spanElt.childNodes[0].nodeValue. You don't need to be all that creative for times. January 1, 1970 23:00 var dates = document.getElementsByName("foo"); Then just iterate through the dates nodeList. So long as you make sure you don't assign name="foo" to anything else other than a date, you're fine. From gerv at mozilla.org Sat Sep 28 07:20:31 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 28 Sep 2002 08:20:31 +0100 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> <3D952D26.3010105@returnzero.com> Message-ID: <3D95583F.1010706@mozilla.org> David Miller wrote: > On 9/27/02 10:16 PM -0600, Christopher A. Aillon wrote: >>Ok so let me clarify. justdave's intent (AIUI) was to store this in the >>database after submitting with a form. My intent is that we should not store >>this stuff in the db. Just rely on the client to do it. Write JS that >>adjusts >>the times by the offset if necessary. I travel in between timezones and want >>this to just work without me fiddling around in preferences. I don't >>want to be >>in NY and see the time in CA. > > Ah, yeah, but then it always depends on the user having Javascript > anyway... And makes things really complicated with international date formats. Far easier to do all this server-side. Gerv From myk at mozilla.org Sat Sep 28 18:28:30 2002 From: myk at mozilla.org (Myk Melez) Date: Sat, 28 Sep 2002 11:28:30 -0700 Subject: corporate win--their requirements References: Message-ID: <3D95F4CE.8000908@mozilla.org> Bradley Baetz wrote: >product views could just be treated as a 'format', or something. > But remember that user views intersect with product views, creating potentially XxY formats. I think we need a more sophisticated approach, like perhaps product-specific and user-specific lists of fields to display along, the union of which comprises the fields we want on the form, along with some means of choosing from several different basic layouts (maybe this can be made role-specific). >>Sybase Support >> >> >At the moment, the answer is 'with great difficultly'. Thats not going to >change for a while, though. > Would we take a hacky implementation (f.e. branching conditionals around database-specific queries) in the meantime? >>Third Level of Categorization (sub-component) >> >> >If someone can come up with a UI, I'd prefer 'infinite level'. Since all >components are unique ids anyway, if you kow the component, then you know >the component's parent, and so on. > I thought so too at one point. Now I'm not so sure, since the implementation complexity of n-level systems increases greatly, while the utility of fourth and subsequent levels drops at the same high rate. >>Reopened Count >> >> >Eww. Why? > Presumably they have some problem with regressions they want to get a handle on. -myk From caillon at returnzero.com Sat Sep 28 18:50:27 2002 From: caillon at returnzero.com (Christopher A. Aillon) Date: Sat, 28 Sep 2002 12:50:27 -0600 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> <3D952D26.3010105@returnzero.com> <3D95583F.1010706@mozilla.org> Message-ID: <3D95F9F3.9060407@returnzero.com> Gervase Markham wrote: > And makes things really complicated with international date formats. Far > easier to do all this server-side. Date.parse() Date.toLocaleString() From gerv at mozilla.org Sat Sep 28 20:10:12 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 28 Sep 2002 21:10:12 +0100 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> <3D952D26.3010105@returnzero.com> <3D95583F.1010706@mozilla.org> <3D95F9F3.9060407@returnzero.com> Message-ID: <3D960CA4.2040600@mozilla.org> Christopher A. Aillon wrote: > Gervase Markham wrote: > >> And makes things really complicated with international date formats. >> Far easier to do all this server-side. > > Date.parse() > Date.toLocaleString() The problem with that is that I don't want every comment in my Bugzilla bug to have a timestamp of the form: Mon 01 Jan 1990 12:00:00 AM BST Ideally, we'd keep using the current, international 2002-08-04 11:43 form. But JavaScript's Date object doesn't have an equivalent of time2str(), where you can supply a format. Maybe (probably) I'm missing something here. If you can provide some JS that turns 1000001234 (server side secs-since-Jan-1970 value) to a client-side 2002-03-03 11:43 , I'll be pleased and impressed. It still won't necessarily make it the right thing to do, though. For example, we need to evaluate the effect of a load of scattered document.write()s on the page display time of a large bug with many comments. I _believe_ the presence of document.write() means rendering has to be delayed on Mozilla, but I could be wrong about that. Gerv From gerv at mozilla.org Sat Sep 28 20:14:57 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 28 Sep 2002 21:14:57 +0100 Subject: corporate win--their requirements References: <3D95F4CE.8000908@mozilla.org> Message-ID: <3D960DC1.4070107@mozilla.org> Myk Melez wrote: > Bradley Baetz wrote: > But remember that user views intersect with product views, creating > potentially XxY formats. I think we need a more sophisticated approach, > like perhaps product-specific and user-specific Group-specific, presumably... > lists of fields to > display along, the union of which comprises the fields we want on the > form, along with some means of choosing from several different basic > layouts (maybe this can be made role-specific). Or we make the layout more modular. E.g. email address fields vertically aligned here, with text fields here, and multi-selects in a horizontal row here, etc. etc. But what about the query page? If you make custom fields product-specific, then each product will need its own query page, because otherwise the query page will be a superset of all possible fields, and a complete nightmare. But then how do you do cross-product queries? A radical idea would be to make them impossible (although we could have an "add to this buglist" feature). This would significantly reduce complexity and page-download time once we have a third level. >>> Third Level of Categorization (sub-component) >> >> If someone can come up with a UI, I'd prefer 'infinite level'. Since >> all components are unique ids anyway, if you kow the component, then >> you know the component's parent, and so on. >> > I thought so too at one point. Now I'm not so sure, since the > implementation complexity of n-level systems increases greatly, while > the utility of fourth and subsequent levels drops at the same high rate. I'm not convinced by the n-level system either. As Myk says, it would be very hard to find a use for more than three levels, and as bbaetz hints, the UI to define the relationships in an n-level system would get really hairy. And the implementation would be hard. Gerv From bugreport at peshkin.net Sat Sep 28 20:07:09 2002 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 28 Sep 2002 13:07:09 -0700 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> <3D94E6F7.3050803@peshkin.net> <3D95164D.8020309@mozilla.org> Message-ID: <3D960BED.80605@peshkin.net> 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) There must be a better way somewhere. -Joel From gerv at mozilla.org Sat Sep 28 20:22:35 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 28 Sep 2002 21:22:35 +0100 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> <3D952D26.3010105@returnzero.com> <3D953B91.4030901@returnzero.com> Message-ID: <3D960F8B.8040806@mozilla.org> > functionality. This is an enhancement though and the people that > typically care about this sort of thing are end users who do have JS > on. Another thought: if someone turns off JS, e.g. for testing, or moves from one computer or browser to another that does or doesn't have JS, all their timestamps will change. This is undesirable. > This is a client related thing and we shouldn't do client things on > the server side. Plus I bet there is some interest in keeping the DB > size down. Three letters per user isn't going to kill anyone's DB. :-) Gerv From caillon at returnzero.com Sat Sep 28 20:59:44 2002 From: caillon at returnzero.com (Christopher A. Aillon) Date: Sat, 28 Sep 2002 14:59:44 -0600 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> <3D952D26.3010105@returnzero.com> <3D95583F.1010706@mozilla.org> <3D95F9F3.9060407@returnzero.com> <3D960CA4.2040600@mozilla.org> Message-ID: <3D961840.9010905@returnzero.com> Gervase Markham wrote: > The problem with that is that I don't want every comment in my Bugzilla > bug to have a timestamp of the form: > Mon 01 Jan 1990 12:00:00 AM BST > > Ideally, we'd keep using the current, international > 2002-08-04 11:43 > form. But JavaScript's Date object doesn't have an equivalent of > time2str(), where you can supply a format. > > Maybe (probably) I'm missing something here. If you can provide some JS > that turns 1000001234 (server side secs-since-Jan-1970 value) to a > client-side 2002-03-03 11:43 , I'll be pleased and impressed. var d = new Date(1017859380000); var mar32k2 = d.getFullYear() + "-" + d.getMonth() + "-" + d.getDay(); var elevenFortyThree = d.toLocaleTimeString(); // 11:43:00 AM // elevenFortyThree = d.getHours() + ":" + d.getMinutes(); // 11:43 var impressive = mar32k2 + " " + elevenFortyThree; > It still won't necessarily make it the right thing to do, though. For > example, we need to evaluate the effect of a load of scattered > document.write()s on the page display time of a large bug with many > comments. I _believe_ the presence of document.write() means rendering > has to be delayed on Mozilla, but I could be wrong about that. Don't use document.write. Use the DOM to manipulate existing pages. I made a post about this earlier in the thread. > > Gerv > > ---- > To view or change your list settings, click here: > > > From gerv at mozilla.org Sat Sep 28 21:04:00 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 28 Sep 2002 22:04:00 +0100 Subject: Ideas for more use of TT Message-ID: <3D961940.20907@mozilla.org> A refresher look at the TT manual yielded the following ideas: Compile Time Constant Folding http://www.template-toolkit.org/docs/plain/Manual/Variables.html#Compile_Time_Constant_Folding Should we be using this facility for things like VERSION and all the stuff that's always included? Autoformat/Wrap http://www.template-toolkit.org/docs/plain/Manual/Plugins.html#Autoformat http://www.template-toolkit.org/docs/plain/Manual/Plugins.html#Wrap Should we be using either of these plugins instead of Text::Format? Date http://www.template-toolkit.org/docs/plain/Manual/Plugins.html#Date Should we be using this for the date/time stuff? It delegates to POSIX strftime. GD I plan to read up on the GD interfaces and maybe use them for reporting, or the generic charting module :-) Gerv From gerv at mozilla.org Sat Sep 28 21:04:33 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 28 Sep 2002 22:04:33 +0100 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D94C99A.8000304@mozilla.org> <3D9514AF.4080103@mozilla.org> Message-ID: <3D961961.8040200@mozilla.org> 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? >>> Pull-down Menu of Assignees >> >> This is a FRFE. We should do it by using a template to define the UI >> for user selection wherever it occurs, and making that template do all >> the work. > > What's an FRFE? Frequent Request For Enhancement :-) >>> System Configuration Fields >> >> Can we not support this request using enter_bug.cgi comment-formatting >> templates? Or do they want to query efficiently for all bugs filed by >> anyone using a Pentium IV processor? > > The latter. Arse. Custom fields it is, then. Gerv From gerv at mozilla.org Sat Sep 28 21:27:39 2002 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 28 Sep 2002 22:27:39 +0100 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> <3D952D26.3010105@returnzero.com> <3D95583F.1010706@mozilla.org> <3D95F9F3.9060407@returnzero.com> <3D960CA4.2040600@mozilla.org> <3D961840.9010905@returnzero.com> Message-ID: <3D961ECB.9040302@mozilla.org> >> Maybe (probably) I'm missing something here. If you can provide some >> JS that turns 1000001234 (server side secs-since-Jan-1970 value) to a >> client-side 2002-03-03 11:43 , I'll be pleased and impressed. > > var d = new Date(1017859380000); > var mar32k2 = d.getFullYear() + "-" + d.getMonth() + "-" + d.getDay(); Not necessarily, if the server is already on a different day from the client. Remember, d is an object representing a server time. Also, getMonth requires 1 adding to it, and zero-padding, and you mean getDate(), not getDay(), and that needs zero-padding, too. > var elevenFortyThree = d.toLocaleTimeString(); // 11:43:00 AM toLocaleTimeString is JS 1.5, available on IE 5.5 and Netscape 6 and above only. Does toLocaleTimeString automatically add on the relevant delta for the user's time zone compared to GMT? That would be wrong anyway, because we need to modify the date based on the time zone difference between the _server_ and the client, because dates are going to continue to be stored on the server in the server's time zone. (Converting to GMT would be a backwards-compatibility nightmare, and more complicated for admins.) (Also, there's the problems I raised about not having JS, which you could comment on at the bottom of this mail for simplicity, if you like.) Gerv From tobias.burnus at physik.fu-berlin.de Sat Sep 28 22:10:47 2002 From: tobias.burnus at physik.fu-berlin.de (Tobias Burnus) Date: Sun, 29 Sep 2002 00:10:47 +0200 (CEST) Subject: Ideas for more use of TT In-Reply-To: <3D961940.20907@mozilla.org> Message-ID: Hi, On Sat, 28 Sep 2002, Gervase Markham wrote: > Date > http://www.template-toolkit.org/docs/plain/Manual/Plugins.html#Date > Should we be using this for the date/time stuff? It delegates to POSIX > strftime. See also: http://bugzilla.mozilla.org/show_bug.cgi?id=162664 POSIX calls create problems under Windows. Tobias From jacob.steenhagen at us.army.mil Sat Sep 28 23:30:46 2002 From: jacob.steenhagen at us.army.mil (PFC Steenhagen, Jacob) Date: Sat, 28 Sep 2002 19:30:46 -0400 Subject: corporate win--their requirements References: <3D948D32.1020509@mozilla.org> <3D9528C9.1090301@returnzero.com> <3D952D26.3010105@returnzero.com> <3D95583F.1010706@mozilla.org> <3D95F9F3.9060407@returnzero.com> <3D960CA4.2040600@mozilla.org> <3D961840.9010905@returnzero.com> <3D961ECB.9040302@mozilla.org> Message-ID: <3D963BA6.2000004@us.army.mil> Perhaps "Use JavaScript to detect whenever I login" (presumably when you change time zones you also change IP's and therefore would be forced to login again) could be one of the time zone options... a bit more work than not having it, but less hassle then getting JS that will work on every browser w/out being slower. Granted, you'd then be stuck on whatever the server's default is until you logged in, but that's the case for anything that doesn't include JavaScript on every page. Gervase Markham wrote: >>> Maybe (probably) I'm missing something here. If you can provide some >>> JS that turns 1000001234 (server side secs-since-Jan-1970 value) to >>> a client-side 2002-03-03 11:43 , I'll be pleased and impressed. >> >> >> var d = new Date(1017859380000); >> var mar32k2 = d.getFullYear() + "-" + d.getMonth() + "-" + d.getDay(); > > > Not necessarily, if the server is already on a different day from the > client. Remember, d is an object representing a server time. > > Also, getMonth requires 1 adding to it, and zero-padding, and you mean > getDate(), not getDay(), and that needs zero-padding, too. > >> var elevenFortyThree = d.toLocaleTimeString(); // 11:43:00 AM > > > toLocaleTimeString is JS 1.5, available on IE 5.5 and Netscape 6 and > above only. > > Does toLocaleTimeString automatically add on the relevant delta for > the user's time zone compared to GMT? That would be wrong anyway, > because we need to modify the date based on the time zone difference > between the _server_ and the client, because dates are going to > continue to be stored on the server in the server's time zone. > (Converting to GMT would be a backwards-compatibility nightmare, and > more complicated for admins.) > > (Also, there's the problems I raised about not having JS, which you > could comment on at the bottom of this mail for simplicity, if you like.) > > Gerv > > > ---- > To view or change your list settings, click here: > From tobias.burnus at physik.fu-berlin.de Sat Sep 28 23:59:00 2002 From: tobias.burnus at physik.fu-berlin.de (Tobias Burnus) Date: Sun, 29 Sep 2002 01:59:00 +0200 (CEST) Subject: corporate win--their requirements In-Reply-To: <3D963BA6.2000004@us.army.mil> Message-ID: Hi, On Sat, 28 Sep 2002, PFC Steenhagen, Jacob wrote: > Perhaps "Use JavaScript to detect whenever I login" (presumably when you > change time zones you also change IP's and therefore would be forced to > login again) could be one of the time zone options... a bit more work > than not having it, but less hassle then getting JS that will work on > every browser w/out being slower. Granted, you'd then be stuck on > whatever the server's default is until you logged in, but that's the > case for anything that doesn't include JavaScript on every page. This starts to get really complicated if one really wants to support (a) Javascript which displays the time strings in local time and (b) to support it for non javascript. This is due to the fact that there are strings passed to the time2str function, including localized versions (see below). Additionally I don't think it is very transparent if the number changes depending whether I have javascript enabled or not. Current strings passed to time2str in current Bugzilla CVS: '%H:%M on the %o of %B, %Y' "%A, %e. %B %Y, %T (%Z)" '%Y/%m/%d %H:%M:%S' "%Y-%m-%d %H:%M" "%D %H:%M" "%Y-%m-%d %H:%M:%S" And in my bugzilla-de I have: "%H:%M am %o %B %Y" "%A, %e. %B %Y, %T (%Z)" If you now additionally consider "August vs. Aout" "Tuesday vs. Dienstag" it becomes really messy. Tobias From bbaetz at student.usyd.edu.au Sun Sep 29 02:06:41 2002 From: bbaetz at student.usyd.edu.au (Bradley Baetz) Date: Sun, 29 Sep 2002 12:06:41 +1000 (EST) Subject: Ideas for more use of TT In-Reply-To: <3D961940.20907@mozilla.org> Message-ID: On Sat, 28 Sep 2002, Gervase Markham wrote: > A refresher look at the TT manual yielded the following ideas: > > Compile Time Constant Folding > > http://www.template-toolkit.org/docs/plain/Manual/Variables.html#Compile_Time_Constant_Folding > Should we be using this facility for things like VERSION and all the > stuff that's always included? Yes, although we'd then need ot ahve the constants pushed in all teh testing places (plus require 2.08). I think we need Bugzilla::Template first, so that all this is in one place. > > Autoformat/Wrap > > http://www.template-toolkit.org/docs/plain/Manual/Plugins.html#Autoformat > http://www.template-toolkit.org/docs/plain/Manual/Plugins.html#Wrap > Should we be using either of these plugins instead of Text::Format? > Myk used Wrap for RT. > Date > > http://www.template-toolkit.org/docs/plain/Manual/Plugins.html#Date > > Should we be using this for the date/time stuff? It delegates to POSIX > strftime. > IS that available on windows, is the question. > GD > > I plan to read up on the GD interfaces and maybe use them for reporting, > or the generic charting module :-) > Thats fine > Gerv > Bradley From gerv at mozilla.org Mon Sep 30 20:35:53 2002 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 30 Sep 2002 21:35:53 +0100 Subject: Online Help Message-ID: <3D98B5A9.6050402@mozilla.org> There's a patch for context-sensitive help over in http://bugzilla.mozilla.org/show_bug.cgi?id=114179 (needs review, if anyone thinks it's worth having) , but this message is more about things like the Bug Writing Guidelines. I produced a patch to make these a page.cgi page (so they got a header, footer etc.) but matty made the point that this stuff should perhaps be in our end-user documentation, which is currently Section 3 of the Bugzilla Guide. So we need to have a discussion about our strategy. There seem to be a couple of routes for page-based help: - page.cgi-based pages. Pros: Bugzilla look and feel Cons: possible duplication of material with that in the Guide - link directly to pages in the Guide Pros: One source for Bugzilla usage information Cons: Possible that manual and online help require different styles Harder to translate Views? Gerv