From lpsolit at gmail.com Wed May 2 12:28:48 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 02 May 2007 14:28:48 +0200 Subject: Minutes of the last 2 Bugzilla meetings Message-ID: <46388400.9040504@gmail.com> Hi all, I finally wrote the minutes of the last 2 Bugzilla meetings: http://wiki.mozilla.org/Bugzilla:Meetings:2007-02-27 http://wiki.mozilla.org/Bugzilla:Meetings:2007-03-20 As you can see, we didn't meet since March 20, due to a lack of items to discuss and because the activity is rather low these last few weeks. The meeting targetted to April 17 has been canceled, just in case you wondered. The next one is scheduled on May 15 at 18:00 GMT (11:00 PST, 20:00 CEST). Note that we now meet once per month while the trunk is open, as we generally have very few things to discuss. LpSolit From mkanat at bugzilla.org Thu May 3 00:30:00 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 2 May 2007 17:30:00 -0700 Subject: The Problems of Perl: The Future of Bugzilla Message-ID: <20070503003115.DFF301817A@help.trusthosting.net> [ Note: This entire post is also available in HTML on my blog: http://avatraxiom.livejournal.com/58084.html ] Once upon a time, Bugzilla was an internal application at Netscape, written in TCL. When it was open-sourced in 1998, Terry (the original programmer), decided to re-write Bugzilla in Perl. My understanding is that he re-wrote it in Perl because a lot of system administrators know Perl, so that would make it easier to get contributors. In 1998, there were few advanced, object-oriented web scripting languages. In fact, Perl was pretty much it. PHP was at version 3.0, python was at version 1.5, Java was just starting to become well-known, ruby was almost unheard of, and some people were still writing their CGI scripts in C or C++. Perl has many great features, most of all the number of libraries available and the extreme flexibility of the language. However, Perl would not be my first choice for writing or maintaining a large project, such as Bugzilla. The same flexibility that makes Perl so powerful makes it very difficult to enforce code quality standards or to implement modern object-oriented designs. Here are the problems: * Reviewing Perl code takes much longer than reviewing other languages. Here's why: o There are many ways to do the same thing in Perl. It's even the motto: "There's More Than One Way To Do It." However, this means that each reviewer must enforce very strict code guidlines on each coder, or must learn each coder's coding style. In the interest of consistency, we usually pick the former. This takes more reviewer time. It's also frustrating for contributors who are used to writing in a particular fashion. o More ways to write the same thing means there are many more *bad* ways to write code in Perl than there are in other languages. In any language it's *possible* to do stupid things and not realize it. In Perl it's easy. Or even when the code does what you mean it to, just because it *works* doesn't mean it's good. My experience is that Perl encourages people to write code that "just works," but might not be architected appropriately. Once again, this is possible in any language, but I think Perl makes it easier than other languages to write bad code. o It's very easy to make Perl code hard to read. It uses strange variables like $_. It relies heavily on complex regular expressions. I don't think anybody would argue that Perl *encourages* readability. * Perl lacks many of the features that implement what computer scientists call "design by contract." That is, Perl doesn't enforce things. For example, Perl doesn't check the type of arguments to subroutines. You can't make subroutines private in a class. Programmers have to actually read the documentation to know that a function is really "private" or "protected." Perl doesn't have real assertions. (The "assert" command in C, Python, Java, or various other languages.) Perl's lack of enforcement is a nice feature for the casual programmer, but for the design of large applications, you want the programming langugae itself to do as much error-checking for you as possible, so that you don't have to write the error-checking yourself. * Perl lacks a real exception mechanism. We would have to write our own if we want one. * Under mod_perl, because of the design of Perl, Apache processes grow HUGE in size. We kill them if they get up to 70MB, but even 40MB for a single Apache process is too big. The fact that Perl never releases memory back to the kernel is a problem. * Without some experience, it can be difficult to read Perl's compiler error messages and actually then determine what's wrong. Since 1998 there have been many advances in programming languages. PHP has decent object-oriented features, python has many libraries and excellent syntax, Java has matured a lot, and Ruby is coming up in the world quickly. Nowadays, almost all of our competitors have one advantage: they are not written in perl. They can actually develop features more quickly than we can, not because of the number of contributors they have, but because the language they're using allows it. There are at least two bug-trackers that I can think of off the top of my head that didn't even *exist* in 1998 and were developed rapidly up to a point where they could compete with Bugzilla. However, honestly, I like Bugzilla better than all of our competitors. We have almost 10 years of experience writing a bug tracker. We know what people need and want from bug-tracking software. But still, any of you long-term contributors to Bugzilla who also have experience in other languages, ask yourself this question: "In all the time I've spent working on Bugzilla in Perl, how far could I have gotten on writing another bug tracker, from SCRATCH, in another language?" My personal estimate is that I could have entirely re-written Bugzilla in Python or Ruby in half the time I've been working on it in Perl. (That would be re-writing it in a year and a half, not an unreasonable amount of time for 80,000 lines of code or so.) Nowadays, even the virtue of "lots of system administrators speak Perl" is fading. New admins are more likely to know Python than Perl. And in about two years from now, I'll bet people will be just as likely to know Ruby. Perl will continue to fade in popularity, I suspect. Already there's no doubt that far more people know PHP than know Perl. So the popularity argument is dead. One advantage that Perl has is CPAN. There are a lot of libraries available. But then again, that's also a problem that Perl has--people need to install SO MANY modules just to use Bugzilla. Witness all the protesting there is from our users whenever we add new required modules to Bugzilla, and the support questions we get about problems with CPAN. And even that advantage is fading. There are a lot of python modules available now. Java has Jakarta and a lot of other modules. And Ruby has RubyGems, which are even easier to install than CPAN modules. PHP has PEAR, which is also very nice. In 1998, Perl was the right choice for a language to re-write Bugzilla in. In 2007, though, having worked with Perl extensively for years on the Bugzilla project, I'd say the language itself is our greatest hinderance. But what can we do about it? ohloh.net says that we have 43,762 lines of code in Bugzilla (http://www.ohloh.net/projects/3524), and I think we might even have twice that many, if you count templates. Not to mention POD. I think that the experience of Netscape and the Mozilla Project shows us that re-writing Bugzilla from scratch and totally ignoring our old code base would be a bad idea. If we stopped development for a year and a half, we'd be hopelessly behind and our users would start to abandon us in droves. As far as I can see, if we want to move away from Perl and move to a language that will be better for us as time goes on, we have two choices: 1) Figure out a way to re-write *parts* of Bugzilla in another language without affecting performance or greatly adding to the complexity of installation. We could then incrementally move to another language. 2) Work on both projects at once--a small team working on the re-write in another language, and the same team we have now working on the current Perl version, up until version 3.4 or 3.6. If #1 is possible, I think I'd obviously prefer that. However, if it would be extremely difficult or be somehow bad for the project overall, then we could do #2. No matter which way we go, these are the steps we'd have to go through: 1) Make a list of every single feature of Bugzilla that would have to be re-written in a new version. 2) Using this list, decide on a language to use that would be the easiest and best for implementing all of those features. We could also decide if we want to use a web framework like Rails (Ruby) or Pylons (Python) to eliminate us having to write some code. After all, the less code we have to write, the better. I've already been experimenting with various languages, and I've started a page here that compares their advantages and disadvantages, from Bugzilla's perspective: http://wiki.mozilla.org/Bugzilla:Languages 3) Prototype some basic features of Bugzilla in that language, to see how easy it actually is. 4) Prioritize the feature list of Bugzilla, to figure out what we have to re-implement in what order. 5) Do some design of the system so that it makes sense and is coherent when it's done. We don't have to re-design Bugzilla at this point--we could get stuck in that forever. And we shouldn't design it by committee. One or two people should work on the design, and then present it to others for review. However, no matter what the design is, it's important to maintain feature and API parity with the current Perl Bugzilla--otherwise it will be very hard to get users and extensions to upgrade. 6) Start work, based on the design and the priority list. Without taking some action, I'm not sure how many more years Bugzilla can stay alive as a product. Currently, our popularity is actually *increasing*, as far as I can see. So we shouldn't abandon what we're doing now. But I'm seeing more and more products come into the bug-tracking arena, and I'm not sure that we can stay competetive for more than a few more years if we are stuck with Perl. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From Thorsten.Claus at keytech.de Thu May 3 07:15:16 2007 From: Thorsten.Claus at keytech.de (Thorsten Claus) Date: Thu, 3 May 2007 09:15:16 +0200 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503003115.DFF301817A@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> Message-ID: <20070503071551.007F05B4024@dm-mail02.mozilla.org> I agree with you. Other things you have to consider when you compare the pros and cons of a language is for me: * Windows-available, how easy it is to run ruby / pyton etc under cross-platform environments? * support for designer-tools / debugging assistants I know that there are many Java / PHP / C# Tools, but I don't know any perl/ Ruby etc tools, to support development. From chicks at chicks.net Thu May 3 10:30:21 2007 From: chicks at chicks.net (Christopher Hicks) Date: Thu, 3 May 2007 06:30:21 -0400 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503003115.DFF301817A@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> Message-ID: <20070503103021.GC27899@chicks.net> On Wed, May 02, 2007 at 05:30:00PM -0700, Max Kanat-Alexander wrote: > So the popularity argument is dead. It sure is. For some of us, it was dead from the gitgo because its usually falacious, misinformed, and irrelevant. Considering PHP sems to fall into this same area - why use a knock-off of Perl that's been far buggier and security-hole-prone than anything except for sendmail and Microsoft? If its not because all the other kids are doing it, its hard to believe its because PHP is good. If you're going to steal from Perl, why not keep say dynamic linking and DBI. It would have made the whole thing much less nasty. Those are questions of vision and architecture which PHP totally blew. What are they going to screw up next? If you're insistent on rewriting bugzilla, do it, but not doing it in Perl seems petty and reactionary. I won't run a non-Perl version of bugzilla if that's what happens down the road. I'll rewrite bugzilla in catalyst first. Bugzilla's problems are architectural, not language. There are plenty of techniques (like Perl::Critic and perltidy) to address your concerns. As many have said, spaghetti code can be written in any language. Looking at most PHP projects this is self-evident. Thinking about an architecture is necessary regardless of whether you stick with Perl or not. If you had a Perl app in that architecture wouldn't most of your frustrations diminish? And finally, if you can't handle Perl's flexibility, go back to the side of the circus with all the silly nets and things. We have nets too, but we try to only pull them out when they're NEEDED. -- "Are your girl scout cookies made with real girl scouts?" -- Wednesday Adams From wicked at etlicon.fi Thu May 3 11:47:27 2007 From: wicked at etlicon.fi (Teemu Mannermaa) Date: Thu, 03 May 2007 14:47:27 +0300 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503003115.DFF301817A@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> Message-ID: <4639CBCF.8080001@etlicon.com> On 03.05.2007 03:30, Max Kanat-Alexander wrote: > * Reviewing Perl code takes much longer than reviewing other > languages. At least for me, that's not true. If I would suddenly get a PHP, Python or even, sick, a Ruby review request it would probably take up to 1 year to get into speed. Why? Because I would have to learn the language first. Just like I had to learn Perl back when I was starting to use Bugzilla. Besides, for my review most time goes into looking that the code actually does what it's supposed to do. I do this by testing changed features and not just by looking at the code. Only small fraction of time goes into making sure our style guide rules are met. Usually this can be done by comparing the look of the code to surrounding code. Rest is done with automated tests. If anything, we should extend these automated tests to catch more things we want to enforce. > each reviewer must enforce very strict code guidlines on each coder, or > must learn each coder's coding style. In the interest of consistency, > we usually pick the former. This takes more reviewer time. It's also > frustrating for contributors who are used to writing in a particular > fashion. This could be why patches from known contributors seems to be more easy to review and accept. Or maybe they just don't know yet what objects, utility subroutines, filters and other ready-made items we already have and tend to "reinvent the wheel". If it's the latter then I don't think switching language helps at all. You have to learn these things for each project no matter what language they are written in. I don't know what patch writers think about our rules. For me that's not a problem as I don't know any other way. :) Besides, I thought they are based on globally accepted Style Guide of Perl. > o It's very easy to make Perl code hard to read. It uses strange > variables like $_. It relies heavily on complex regular expressions. I True, but I don't think we have used much those strange variables. Isn't there supposed to be way to write Perl without using them? > don't think anybody would argue that Perl *encourages* readability. Sure, it can have nasty structures that you have never seen before. You can't read a language that you don't know. This applies to every language. > * Without some experience, it can be difficult to read Perl's > compiler error messages and actually then determine what's wrong. I don't think any error message makes any sense if you don't know how things work. > has RubyGems, which are even easier to install than CPAN modules. PHP > has PEAR, which is also very nice. Big question for me is not how easy they are to install myself but rather if there are packages available for them in my platform. Okay, having RPMs makes them very easy to install but it also gets me security updates. I don't want to follow each and every module myself to know when they have a security update out there that I need to install. -- Teemu Mannermaa System Specialist "Anything is possible. It's all about probabilities." From after.fallout at gmail.com Thu May 3 13:53:05 2007 From: after.fallout at gmail.com (Bill Barry) Date: Thu, 03 May 2007 09:53:05 -0400 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4639CBCF.8080001@etlicon.com> References: <20070503003115.DFF301817A@help.trusthosting.net> <4639CBCF.8080001@etlicon.com> Message-ID: <4639E941.2030805@gmail.com> Teemu Mannermaa wrote: > If anything, we should extend these automated tests to catch more > things we want to enforce. How difficult would it be to create tests for code style with a tool like perl-critic? Can we merge tests that others have written? Is it possible to do things like type analysis in perl with tests? Perhaps we need a more suitable structure for some testing. We could probably get a good unit testing design if we were willing to do something like this: * In every directory with a perl script we would have a "t" subdirectory. In that subdirectory there would be a file with the same name as the perl script and a ".t" appended. We can dictate that every function/sub has at least some tests to ensure it works (functionx must have unit_functionx in the test script?). * Rename what is currently the "t" directory in Bugzilla to "designtests" ("t" should be unit/regression tests only) and "runtests.pl" to "styleenforcer.pl" * Create a script with a signature "runtests 'file.pl'" which would run all tests on a given file and any dependant files. * Create another script that would run all tests in Bugzilla. * Make it known that any change to a part of Bugzilla requires new tests, and reviews will be denied on the spot if they don't include test cases. > This could be why patches from known contributors seems to be more > easy to review and accept. Or maybe they just don't know yet what > objects, utility subroutines, filters and other ready-made items we > already have and tend to "reinvent the wheel". If it's the latter then > I don't think switching language helps at all. You have to learn these > things for each project no matter what language they are written in. Switching the language will not help in either case. I have been working on asp.net in c# for a while now (with resharper to help with coding style; everyone has the same configuration). I still end up fixing problems with code design (person uses while loop where they should use a foreach, 3000 line functions, ...). > I don't know what patch writers think about our rules. For me that's > not a problem as I don't know any other way. :) Besides, I thought > they are based on globally accepted Style Guide of Perl. I thought so too. Besides, this is one thing I really like about Bugzilla. I have worked on other projects and just get lost when I try and do something new because suddenly I am in another file with what appears to be an entirely different language. > >> o It's very easy to make Perl code hard to read. It uses strange >> variables like $_. It relies heavily on complex regular expressions. I > > True, but I don't think we have used much those strange variables. > Isn't there supposed to be way to write Perl without using them? The subject can be used for most elegant code as well. Most parts of perl have their purpose and when used correctly can be very readable and easy to understand. From lpsolit at gmail.com Thu May 3 15:39:50 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 03 May 2007 17:39:50 +0200 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4639CBCF.8080001@etlicon.com> References: <20070503003115.DFF301817A@help.trusthosting.net> <4639CBCF.8080001@etlicon.com> Message-ID: <463A0246.3020305@gmail.com> I fully agree with all wicked's comments! Moving away from Perl to another language won't fix anything... except making me leave the project forever. I'm not going to waste my time to learn any new language (I would vomit if you were suggesting JAVA) and to rewrite code which is already working fine as is. And I don't mention all the security holes we will introduce only because we wanted to be more clever than we currently are. Killing Perl-based ssdbot in favor on Python-based buggybot doesn't mean we should also kill Perl-based Bugzilla. Perl-based LpSolit From Nick.Barnes at pobox.com Thu May 3 16:43:51 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Thu, 03 May 2007 17:43:51 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503003115.DFF301817A@help.trusthosting.net> from Max Kanat-Alexander of "Wed, 02 May 2007 17:30:00 -0700" Message-ID: <26647.1178210631@thrush.ravenbrook.com> At 2007-05-03 00:30:00+0000, Max Kanat-Alexander writes [about Perl]. I broadly agree with his views about Perl the language, although the quality of the Perl in Bugzilla has improved enormously since I first worked on it in the 2.10 days. However, I'm not sure that reimplementing in another language is even possible, as the transition might be too ghastly to survive. If one were determined to accomplish this, I guess one would start by choosing a Python templating system (e.g. Cheetah). It looks to me as if converting TT templates into Cheetah could be done in a semi-automated way. One would then start with a minor corner of the CGI, making a hybrid Perl/Python system, and then keep hacking away at converting the Perl until it was all gone. Anyone wanting to fork Bugzilla to do this is of course free to do so, and I would almost certainly contribute some effort to such a project, as well as some expertise and possibly some pre-existing code (if I were doing it myself, I'd start by taking a chainsaw to bugzilla.py and dt_bugzilla.py out of a recent P4DTI). However, it's a long and uncomfortable path and it's not clear whether it's worth the effort. If all I wanted was a system similar to Bugzilla but in a usable language, I would start from scratch. Also, I have a vested interest in Bugzilla remaining Perl: it makes me money in two different ways. Firstly, customizing Bugzilla directly in Perl, which clients are generally unwilling to attempt for themselves. Secondly, providing custom interfaces to Bugzilla in Python, in which clients often are willing to work themselves. This is not a joke: I spent part of today writing a project proposal to do exactly that. This particular client has (as usual) a bunch of custom requirements not met by Bugzilla out of the box. Some of these (as usual) I am doing for them by directly hacking on the Perl. Others (somewhat less usually) they want to do themselves. They have looked at the Perl and decided they want to do it in "a better language" (their term). They have some Python expertise: I will build them a Python interface. Nick B From mkanat at bugzilla.org Thu May 3 17:35:53 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 3 May 2007 10:35:53 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503071551.007F05B4024@dm-mail02.mozilla.org> References: <20070503003115.DFF301817A@help.trusthosting.net> <20070503071551.007F05B4024@dm-mail02.mozilla.org> Message-ID: <20070503173710.6F8828C8001@help.trusthosting.net> On Thu, 3 May 2007 09:15:16 +0200 "Thorsten Claus" wrote: > * Windows-available, how easy it is to run ruby / pyton etc under > cross-platform environments? Yeah, Ruby and Python in particular are actually quite nice and easy to run under Windows. > * support for designer-tools / debugging assistants I know that there > are many Java / PHP / C# Tools, but I don't know any perl/ Ruby etc > tools, to support development. Oh, interesting point. There's a really good interactive shell for Ruby (irb) and Python's is built-in. There are probably other tools I don't know about, also. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu May 3 17:43:11 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 3 May 2007 10:43:11 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4639CBCF.8080001@etlicon.com> References: <20070503003115.DFF301817A@help.trusthosting.net> <4639CBCF.8080001@etlicon.com> Message-ID: <20070503174427.698958C8001@help.trusthosting.net> On Thu, 03 May 2007 14:47:27 +0300 Teemu Mannermaa wrote: > At least for me, that's not true. If I would suddenly get a PHP, > Python or even, sick, a Ruby review request it would probably take up > to 1 year to get into speed. Why? Because I would have to learn the > language first. Just like I had to learn Perl back when I was > starting to use Bugzilla. I think you'd be surprised there. Ruby in particular is extremely easy to learn: http://tryruby.hobix.com/ > Only small fraction of > time goes into making sure our style guide rules are met. Whereas I, on the other hand, spend most of my time there. > This could be why patches from known contributors seems to be more > easy to review and accept. Or maybe they just don't know yet what > objects, utility subroutines, filters and other ready-made items we > already have and tend to "reinvent the wheel". Yes, that's because *we've* "re-invented the wheel" to add features that the language doesn't have, like a base object for all objects. That is, nobody is familiar with what we're doing because we had to make it up, instead of having it be supplied by some framework or the language itself. > I don't know what patch writers think about our rules. For me that's > not a problem as I don't know any other way. :) Yeah--that's one difference in our viewpoints, perhaps. I've used a lot of other languages and I've worked on a lot of other projects, and I know the difference a language and a framework can make. > Besides, I thought > they are based on globally accepted Style Guide of Perl. Yeah, and 10 pages of Developer's Guide. :-) > True, but I don't think we have used much those strange variables. > Isn't there supposed to be way to write Perl without using them? Yes, but we have to enforce it as reviewers. The language doesn't enforce it for us. > Sure, it can have nasty structures that you have never seen before. > You can't read a language that you don't know. This applies to every > language. Yes, but if you'd used Python or Ruby (or Java) extensively, you'd probably see that they're usually inherently more readable. > I don't think any error message makes any sense if you don't know how > things work. Python's are pretty clear, even if they're really basic. (Well, the tracebacks can be hard to read, but hey.) > Big question for me is not how easy they are to install myself but > rather if there are packages available for them in my platform. Okay, > having RPMs makes them very easy to install but it also gets me > security updates. I don't want to follow each and every module myself > to know when they have a security update out there that I need to > install. There are a lot of RPMs available for both Ruby and Python. I don't know exactly how many RubyGems there are available as RPMs--I'd have to investigate that. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From Tomas.Kopal at altap.cz Thu May 3 17:44:34 2007 From: Tomas.Kopal at altap.cz (Tomas Kopal) Date: Thu, 03 May 2007 19:44:34 +0200 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503173710.6F8828C8001@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> <20070503071551.007F05B4024@dm-mail02.mozilla.org> <20070503173710.6F8828C8001@help.trusthosting.net> Message-ID: <463A1F82.1030705@altap.cz> On 3.5.2007 19:35, Max Kanat-Alexander wrote: >> * support for designer-tools / debugging assistants I know that there >> are many Java / PHP / C# Tools, but I don't know any perl/ Ruby etc >> tools, to support development. >> > > Oh, interesting point. There's a really good interactive > shell for Ruby (irb) and Python's is built-in. There are probably other > tools I don't know about, also. > > -Max > There are GUI debuggers for Python (e.g. http://www.digitalpeers.com/pythondebugger/), syntax highlighting built-in in most modern text editors, there is also a plugin for Eclipse for Python development, including code completition aids and debugging (http://pydev.sourceforge.net/). But this decision is not about tools... Tomas From mkanat at bugzilla.org Thu May 3 17:50:57 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 3 May 2007 10:50:57 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4639E941.2030805@gmail.com> References: <20070503003115.DFF301817A@help.trusthosting.net> <4639CBCF.8080001@etlicon.com> <4639E941.2030805@gmail.com> Message-ID: <20070503175213.E85C48C8001@help.trusthosting.net> On Thu, 03 May 2007 09:53:05 -0400 Bill Barry wrote: > How difficult would it be to create tests for code style with a tool > like perl-critic? Can we merge tests that others have written? > > Is it possible to do things like type analysis in perl with tests? > [snip] Sure, lots of things are possible to automate and improve Perl code. But why should we have to write those? Why should we have to *bend* a language to be usable for a large project? These suggestions will add *more* development time to Bugzilla, and my goal is to be able to add more features in *less* development time. > Switching the language will not help in either case. I have been > working on asp.net in c# for a while now (with resharper to help with > coding style; everyone has the same configuration). I still end up > fixing problems with code design (person uses while loop where they > should use a foreach, 3000 line functions, ...). Honestly, ASP is a terrible piece of crap that I wouldn't touch with a ten-foot pole unless I was forced to. That's also a community that has a history of even worse code standards than the Perl or PHP communities. > The subject can be used for most elegant code as well. Most parts of > perl have their purpose and when used correctly can be very readable > and easy to understand. Maybe that's true, but I don't think so. Most of us here have been using Perl extensively for over a year, and so its various strangenesses are normal to us. But for example, even some of the most basic Perl code can be hard to decipher. It took me a long time to realize the difference between [] and (). And when you could use () for a hash and when you had to use {} and make it a hashref. It's little things like that--things intrinsic to the design of Perl--that make it hard to read. You can say "You have to know any language to read it," but I've used Ruby for maybe a total of 1/2 hour in my life, and I find it pretty readable. I could read Python pretty easily after just a few hours of using it. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu May 3 17:55:43 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 3 May 2007 10:55:43 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <26647.1178210631@thrush.ravenbrook.com> References: <26647.1178210631@thrush.ravenbrook.com> Message-ID: <20070503175700.452CB8C8001@help.trusthosting.net> On Thu, 03 May 2007 17:43:51 +0100 Nick Barnes wrote: > I broadly agree with his views about Perl the language, although the > quality of the Perl in Bugzilla has improved enormously since I first > worked on it in the 2.10 days. I'm glad you think so! :-) I certainly agree. It took a lot of work to get there, though--the language doesn't really help out. > If one were determined to accomplish this, I guess one would start by > choosing a Python templating system (e.g. Cheetah). I'm going to look at web frameworks in various languages, probably starting with Pylons in Python and Rails in Ruby. The idea is to prototype some small part of Bugzilla in that framework to see how it would work. Say--just enter_bug.cgi and post_bug.cgi. > It looks to me as > if converting TT templates into Cheetah could be done in a > semi-automated way. I think this is actually true for most templating systems, for our simpler templates. Some would need to be re-written by hand, but they'd probably get simpler. > However, it's a long and uncomfortable path and it's not clear whether > it's worth the effort. If all I wanted was a system similar to > Bugzilla but in a usable language, I would start from scratch. And that's what many people have done. I like Bugzilla, though. > Also, I have a vested interest in Bugzilla remaining Perl: it makes me > money in two different ways. Firstly, customizing Bugzilla directly > in Perl, which clients are generally unwilling to attempt for > themselves. Secondly, providing custom interfaces to Bugzilla in > Python, in which clients often are willing to work themselves. I think that's an excellent demonstration of why it *should* be transitioned to another language. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu May 3 17:57:04 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 3 May 2007 10:57:04 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <463A0246.3020305@gmail.com> References: <20070503003115.DFF301817A@help.trusthosting.net> <4639CBCF.8080001@etlicon.com> <463A0246.3020305@gmail.com> Message-ID: <20070503175820.8E2EA8C8001@help.trusthosting.net> On Thu, 03 May 2007 17:39:50 +0200 Fr?d?ric Buclin wrote: > I'm not going to waste my time to learn any new language [snip] Try Ruby for about 15 minutes: http://tryruby.hobix.com/ Just type "help" to start the tutorial. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From after.fallout at gmail.com Thu May 3 19:14:11 2007 From: after.fallout at gmail.com (Bill Barry) Date: Thu, 03 May 2007 15:14:11 -0400 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503175213.E85C48C8001@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> <4639CBCF.8080001@etlicon.com> <4639E941.2030805@gmail.com> <20070503175213.E85C48C8001@help.trusthosting.net> Message-ID: <463A3483.10605@gmail.com> Max Kanat-Alexander wrote: > Honestly, ASP is a terrible piece of crap that I wouldn't touch > with a ten-foot pole unless I was forced to. That's also a community > that has a history of even worse code standards than the Perl or PHP > communities. While I would agree about classic ASP, the .NET model has changed that very much. From pdemarco at zoominternet.net Thu May 3 21:43:45 2007 From: pdemarco at zoominternet.net (Paul) Date: Thu, 03 May 2007 17:43:45 -0400 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503003115.DFF301817A@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> Message-ID: <1178228625.16919.10.camel@mainpc> On Wed, 2007-05-02 at 17:30 -0700, Max Kanat-Alexander wrote: > [ Note: This entire post is also available in HTML on my blog: > http://avatraxiom.livejournal.com/58084.html ] The one thing I don't understand is why you don't go off and make something new? If Bugzilla is going to die because of Perl, let it. How does that effect your idea to rewrite it? I think that you should make a product to compete with Bugzilla in a language of your choice. Let the users decide what they want to use. Personally I were going to pick on Bugzilla for something it wouldn't be perl, it would be the name "Bugzilla". From mkanat at bugzilla.org Fri May 4 23:03:53 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 4 May 2007 16:03:53 -0700 Subject: Help For Release of Bugzilla 3.0 Message-ID: <20070504230511.D23A018038@help.trusthosting.net> Hey hey. So it's release time again, this time for Bugzilla 3.0, a Big Deal. (Hahahaha, I first typed "Bug" instead of "Big." Maybe it is a Bug Deal, too.) Here's the list of things that we have to do: https://bugzilla.mozilla.org/showdependencytree.cgi?id=374620&hide_resolved=1 However, what I'd most like to have is some reviews. Anybody can do reviews on these things, you don't have to be an approved reviewer. I'm just interested in some feedback, on these things: Release/News Announcements: https://bugzilla.mozilla.org/show_bug.cgi?id=379775 Status Update: https://bugzilla.mozilla.org/show_bug.cgi?id=379772 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Sat May 5 06:25:05 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 4 May 2007 23:25:05 -0700 Subject: bzr mirror for Bugzilla Message-ID: <20070505062623.0B7F318038@help.trusthosting.net> For anybody who's interested, I'm running a mirror of Bugzilla CVS in bzr that's updated nightly. Right now I'm only making the 3.0 branch and the trunk available, but if anybody wants anything else, just email me. It's really easy to set up a new one. 3.0 branch: bzr co http://bzr.everythingsolved.com/bugzilla/3.0/ Trunk: bzr co http://bzr.everythingsolved.com/bugzilla/trunk/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From gerv at mozilla.org Mon May 7 14:03:08 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 May 2007 10:03:08 -0400 Subject: MySQL, UTF-8 and migration Message-ID: <463F319C.4060607@mozilla.org> Is this useful information for us? http://www.orthogonalthought.com/blog/index.php/2007/05/mysql-database-migration-and-special-characters/ Gerv From gerv at mozilla.org Tue May 8 22:00:58 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 08 May 2007 18:00:58 -0400 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503003115.DFF301817A@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> Message-ID: <4640F31A.5030508@mozilla.org> It's taken me a while to read and think about this; apologies for that. Max Kanat-Alexander wrote: > * Reviewing Perl code takes much longer than reviewing other > languages. I don't agree. I find reviewing Perl takes much less time than reviewing code in other languages. This is because I know Perl, so finding that reviewing it is easier is not a surprise. > o There are many ways to do the same thing in Perl. It's even the > motto: "There's More Than One Way To Do It." However, this means that > each reviewer must enforce very strict code guidlines on each coder, or > must learn each coder's coding style. In the interest of consistency, > we usually pick the former. This takes more reviewer time. It's also > frustrating for contributors who are used to writing in a particular > fashion. Can you cite recent examples of such frustrated contributors? > o More ways to write the same thing means there are many more *bad* > ways to write code in Perl than there are in other languages. In any > language it's *possible* to do stupid things and not realize it. In > Perl it's easy. Or even when the code does what you mean it to, just > because it *works* doesn't mean it's good. My experience is that Perl > encourages people to write code that "just works," but might not be > architected appropriately. Once again, this is possible in any > language, but I think Perl makes it easier than other languages to > write bad code. Can you cite recent examples of code submissions of poor quality? Do you really think we would get fewer poor quality submissions if Bugzilla was written in Python? Poor quality code is caused by writing things too quickly and focussed only on your own needs. This is not a language-specific problem. > o It's very easy to make Perl code hard to read. It uses strange > variables like $_. It relies heavily on complex regular expressions. I > don't think anybody would argue that Perl *encourages* readability. If you don't like that, let's "use English;". It would be the work of a couple of hours to convert the codebase, should we choose. But again, name examples of when this has been a problem. > * Perl lacks many of the features that implement what computer > scientists call "design by contract." That is, Perl doesn't enforce > things. For example, Perl doesn't check the type of arguments to > subroutines. You can't make subroutines private in a class. Programmers > have to actually read the documentation to know that a function is > really "private" or "protected." Examples of bad patches which erroneously used internal functions? To summarise the above: you say that Perl has all these disadvantages in terms of gaining contributors and patch quality. Do you have any evidence to support these assertions? > * Perl lacks a real exception mechanism. We would have to write our > own if we want one. Do we? I think we manage fine without. Web applications seem suited to our Throw*Error-style error handling. > * Under mod_perl, because of the design of Perl, Apache processes > grow HUGE in size. We kill them if they get up to 70MB, but even 40MB > for a single Apache process is too big. The fact that Perl never > releases memory back to the kernel is a problem. I believe you already had suggestions and offers of help to deal with this issue from mod_perl hackers on your blog. > Since 1998 there have been many advances in programming languages. > PHP has decent object-oriented features, python has many libraries and > excellent syntax, Java has matured a lot, and Ruby is coming up in the > world quickly. Right. But I don't see any of them being so much better than Perl that a rewrite would be a net gain. > Nowadays, almost all of our competitors have one advantage: they are > not written in perl. They can actually develop features more quickly > than we can, not because of the number of contributors they have, but > because the language they're using allows it. There are at least two > bug-trackers that I can think of off the top of my head that didn't > even *exist* in 1998 and were developed rapidly up to a point where > they could compete with Bugzilla. Then why don't we/you stop work on Bugzilla and go and work on those? If they are already competitive, it surely makes more sense to enhance what already exists. > But still, any of you long-term contributors to Bugzilla who also > have experience in other languages, ask yourself this question: "In all > the time I've spent working on Bugzilla in Perl, how far could I have > gotten on writing another bug tracker, from SCRATCH, in another > language?" My personal estimate is that I could have entirely > re-written Bugzilla in Python or Ruby in half the time I've been > working on it in Perl. (That would be re-writing it in a year and a > half, not an unreasonable amount of time for 80,000 lines of code or > so.) 80,000 lines of debugged, production-quality code in a man year and a half? That's way, way outside normal metrics. Think about it, though: a man year and a half or more of work - unpaid work - just to stand still. Any business which did that would go under. Say it made adding features and fixing bugs after that time twice as quick (a generous estimate). We'd have to do another man year and a half of unpaid work before it got to the stage where we were better off than if we had stuck with Perl. The numbers here suck. > One advantage that Perl has is CPAN. There are a lot of libraries > available. But then again, that's also a problem that Perl has--people > need to install SO MANY modules just to use Bugzilla. Witness all the > protesting there is from our users whenever we add new required modules > to Bugzilla, and the support questions we get about problems with CPAN. > > And even that advantage is fading. There are a lot of python modules > available now. Java has Jakarta and a lot of other modules. And Ruby > has RubyGems, which are even easier to install than CPAN modules. PHP > has PEAR, which is also very nice. Requiring lots of modules is either a good thing or a bad thing. Decide! :-) > In 1998, Perl was the right choice for a language to re-write > Bugzilla in. In 2007, though, having worked with Perl extensively for > years on the Bugzilla project, I'd say the language itself is our > greatest hinderance. I don't agree. I think lack of developer time is our greatest hindrance. I also think that Bugzilla is a mature application. Other bug trackers have fast development partly because they don't have all the features we do yet. > 1) Figure out a way to re-write *parts* of Bugzilla in another > language without affecting performance or greatly adding to the > complexity of installation. We could then incrementally move to another > language. ...and make it twice as hard to install for the intermediate period. :-) > 2) Work on both projects at once--a small team working on the > re-write in another language, and the same team we have now working on > the current Perl version, up until version 3.4 or 3.6. If you want to go and do this, I can't stop you :-) It's free software. But here's an alternative scenario. We continue working on Bugzilla in Perl. If and when no-one is using it any more because there are better alternatives, and/or there is no-one interested in developing it any more, we stop, and the world continues to revolve, and free software development continues using another tool or tools. Bugzilla enters the Software Hall of Fame. If you want a bug-tracker in Language X, go write one in Language X or work on one of the existing ones in Language X. Or, if you really think it's the best way forward, fork Bugzilla and incrementally rewrite it in Language X, with whoever you can persuade to help. But I would be very much against the Bugzilla project making this a main or even a supported line of development. Of course, my viewpoint needs to be weighed taking into account the level of my contributions recently. Gerv From mkanat at bugzilla.org Wed May 9 16:55:05 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 9 May 2007 09:55:05 -0700 Subject: dkl can do reviews Message-ID: <20070509165633.CA5E58C8017@help.trusthosting.net> I just wanted to let everybody know that an old Bugzilla reviewer has returned to the team, and is available for reviews, Dave Lawrence from Red Hat, dkl at redhat.com. If you have any old reviews that haven't had anybody look at them in a long time, feel free to redirect them to him. :-D (That's an evil grin, there.) As he's coming back to the team, right now he needs another reviewer to super-review his reviews, but that should change after a few weeks or so. -Max From jochen.wiedmann at gmail.com Wed May 9 17:30:17 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Wed, 9 May 2007 19:30:17 +0200 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4640F31A.5030508@mozilla.org> References: <20070503003115.DFF301817A@help.trusthosting.net> <4640F31A.5030508@mozilla.org> Message-ID: On 5/9/07, Gervase Markham wrote: > > * Perl lacks a real exception mechanism. We would have to write our > > own if we want one. > > Do we? I think we manage fine without. Web applications seem suited to > our Throw*Error-style error handling. Apart from that, that's simply not true. One can throw and catch arbitrary objects in Perl. What's the difference to a "real exception mechanism"? Why Bugzilla doesn't use, for example, DBI's RaiseError flag, is something I never understood. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From mkanat at bugzilla.org Wed May 9 21:50:19 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 9 May 2007 14:50:19 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <20070503003115.DFF301817A@help.trusthosting.net> <4640F31A.5030508@mozilla.org> Message-ID: <20070509215144.8EB9A118034@help.trusthosting.net> On Wed, 9 May 2007 19:30:17 +0200 "Jochen Wiedmann" wrote: > Why Bugzilla doesn't use, for example, DBI's RaiseError > flag, is something I never understood. It does. You mean turn it off? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jochen.wiedmann at gmail.com Thu May 10 06:22:09 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Thu, 10 May 2007 08:22:09 +0200 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070509215144.8EB9A118034@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> <4640F31A.5030508@mozilla.org> <20070509215144.8EB9A118034@help.trusthosting.net> Message-ID: On 5/9/07, Max Kanat-Alexander wrote: > > Why Bugzilla doesn't use, for example, DBI's RaiseError > > flag, is something I never understood. > > It does. You mean turn it off? Then it's too far away when I've been reading the Bugzilla sources, in which case I apologize. But then, you are using exception handling. So, what's wrong with that? Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From Guillaume.Rousse at inria.fr Thu May 10 14:55:42 2007 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Thu, 10 May 2007 16:55:42 +0200 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503003115.DFF301817A@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> Message-ID: <4643326E.5080208@inria.fr> Max Kanat-Alexander a ?crit : > o There are many ways to do the same thing in Perl. It's even the > motto: "There's More Than One Way To Do It." However, this means that > each reviewer must enforce very strict code guidlines on each coder, or > must learn each coder's coding style. In the interest of consistency, > we usually pick the former. This takes more reviewer time. It's also > frustrating for contributors who are used to writing in a particular > fashion. Establish a standard perltidy configuration file. And use a dedicated framework to impose your prefered style, such as Perl::Critic. > o More ways to write the same thing means there are many more *bad* > ways to write code in Perl than there are in other languages. In any > language it's *possible* to do stupid things and not realize it. In > Perl it's easy. Or even when the code does what you mean it to, just > because it *works* doesn't mean it's good. My experience is that Perl > encourages people to write code that "just works," but might not be > architected appropriately. Once again, this is possible in any > language, but I think Perl makes it easier than other languages to > write bad code. You never used visual basic, with its magic ANY type, or other beginners-oriented languages, do you ? > o It's very easy to make Perl code hard to read. It uses strange > variables like $_. It relies heavily on complex regular expressions. I > don't think anybody would argue that Perl *encourages* readability. It doesn't force you, at least. Being an advantage or an inconvenient is a matter or taste. > * Perl lacks many of the features that implement what computer > scientists call "design by contract." Very few languages (eiffel, at least) really enforce design by contract. > That is, Perl doesn't enforce > things. For example, Perl doesn't check the type of arguments to > subroutines. As most (all ?) dynamically typed languages. Many modules allow you to do it, tough (see Params::Validate, for instance). > You can't make subroutines private in a class. You can have anonymous or lexical subroutines references. > Programmers > have to actually read the documentation to know that a function is > really "private" or "protected." Perl doesn't have real assertions. > (The "assert" command in C, Python, Java, or various other languages.) See Carp::Assert. > Perl's lack of enforcement is a nice feature for the casual > programmer, but for the design of large applications, you want the > programming langugae itself to do as much error-checking for you as > possible, so that you don't have to write the error-checking yourself. > > * Perl lacks a real exception mechanism. We would have to write our > own if we want one. See Exception::Class. [..] > One advantage that Perl has is CPAN. There are a lot of libraries > available. But then again, that's also a problem that Perl has--people > need to install SO MANY modules just to use Bugzilla. Witness all the > protesting there is from our users whenever we add new required modules > to Bugzilla, and the support questions we get about problems with CPAN. Well, bugzilla packages from linux distributions are installable with one command only. By making bugzilla available on CPAN, as as RT is already, for instance, you could also make it available with a single command. You could even distribute it as a perl packages bundle. They are lots of standard distribution models already adressing this dependency issue. Current home-made bugzilla installation model, on the other hand (such as providing CVS files), just encourage users to manually install and upgrade their running system. Some large perl software (catalyst, RT) draw half of CPAN as dependencies. This doesn't prevent them to be widely used. Of course, if you target typical windows users whose only experience of software installation is click'n'run self-extractable installers, you'll get such kind of protestation. It's up to you to decide between software engineering practices, and unaware users popularity. Many of the problem you're exposing here are valid. And as such, have already been handled inside perl community. Maybe learning from this community would help there ? I recommand reading 'Perl Best Practices', by D. Conway, for instance. Or even joining some perl conference to present bugzilla, and discuss those issues directly with people. BTW, your post has also been discussed here: http://use.perl.org/~chromatic/journal/33191 -- Guillaume Rousse Moyen Informatiques - INRIA Futurs Tel: 01 69 35 69 62 From jochen.wiedmann at gmail.com Fri May 11 07:40:43 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 11 May 2007 09:40:43 +0200 Subject: Dynamic parameters Message-ID: Hi, I have a use case, which I'd like to discuss here. I've got a Bugzilla installation, which is located between two networks. In other words, it has two IP addresses. That's not unusual, but unfortunately noth IP addresses are unreachable from the respective other network. (This cannot be changed: The machine is sitting between two large corporate networks and I do not have any influence on the routing.) In other words, I am forced to change the "urlbase" parameter, depending on the clients IP address. Currently I do that by hacking Bugzill::Config->Param with a regexp of s/^([^\:]+\:\/\/)([\w\.\-]+)(.*)/$1$ENV{'SERVER_NAME'}$3/ I wonder whether I am the only one with a similar use case. Are there any hooks in Bugzilla, which would allow me to remove my ugly hack? Or would `such a hook be a valuable contribution? Thanks, Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From pdemarco at zoominternet.net Fri May 11 09:49:25 2007 From: pdemarco at zoominternet.net (Paul) Date: Fri, 11 May 2007 05:49:25 -0400 Subject: Dynamic parameters In-Reply-To: References: Message-ID: <1178876965.16919.14.camel@mainpc> My suggestion is to use the same dns name. Or create an alias that is the name you want to use for both. Then each can resolve to a different IP address depending on which side you're on and you keep your sanity. On Fri, 2007-05-11 at 09:40 +0200, Jochen Wiedmann wrote: > Hi, > > I have a use case, which I'd like to discuss here. > > I've got a Bugzilla installation, which is located between two > networks. In other words, it has two IP addresses. That's not unusual, > but unfortunately noth IP addresses are unreachable from the > respective other network. (This cannot be changed: The machine is > sitting between two large corporate networks and I do not have any > influence on the routing.) > > In other words, I am forced to change the "urlbase" parameter, > depending on the clients IP address. Currently I do that by hacking > Bugzill::Config->Param with a regexp of > > s/^([^\:]+\:\/\/)([\w\.\-]+)(.*)/$1$ENV{'SERVER_NAME'}$3/ > > I wonder whether I am the only one with a similar use case. Are there > any hooks in Bugzilla, which would allow me to remove my ugly hack? Or > would `such a hook be a valuable contribution? > > Thanks, > > Jochen > From jochen.wiedmann at gmail.com Fri May 11 10:03:42 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 11 May 2007 12:03:42 +0200 Subject: Dynamic parameters In-Reply-To: <1178876965.16919.14.camel@mainpc> References: <1178876965.16919.14.camel@mainpc> Message-ID: On 5/11/07, Paul wrote: > My suggestion is to use the same dns name. Or create an alias that is > the name you want to use for both. Then each can resolve to a different > IP address depending on which side you're on and you keep your sanity. You can assign two IP addresses to one host name. But then, you cannot control, which IP address the client will choose. No, I can't see that DNS is the solution. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From gerv at mozilla.org Fri May 11 10:16:47 2007 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 11 May 2007 11:16:47 +0100 Subject: Dynamic parameters In-Reply-To: References: <1178876965.16919.14.camel@mainpc> Message-ID: <4644428F.6020108@mozilla.org> Jochen Wiedmann wrote: > On 5/11/07, Paul wrote: > >> My suggestion is to use the same dns name. Or create an alias that is >> the name you want to use for both. Then each can resolve to a different >> IP address depending on which side you're on and you keep your sanity. > > You can assign two IP addresses to one host name. But then, you cannot > control, which IP address the client will choose. No, I can't see that > DNS is the solution. I think he is suggesting that you assign different IP addresses to the same hostname, but one in the DNS server for corporate network A and the other in the DNS server for corporate network B. Unless you are saying that the two networks, despite being entirely unconnected, share the same DNS servers? Gerv From aaron.trevena at gmail.com Fri May 11 11:59:54 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Fri, 11 May 2007 12:59:54 +0100 Subject: Dynamic parameters In-Reply-To: <4644428F.6020108@mozilla.org> References: <1178876965.16919.14.camel@mainpc> <4644428F.6020108@mozilla.org> Message-ID: On 11/05/07, Gervase Markham wrote: > Jochen Wiedmann wrote: > > On 5/11/07, Paul wrote: > > > >> My suggestion is to use the same dns name. Or create an alias that is > >> the name you want to use for both. Then each can resolve to a different > >> IP address depending on which side you're on and you keep your sanity. > > > > You can assign two IP addresses to one host name. But then, you cannot > > control, which IP address the client will choose. No, I can't see that > > DNS is the solution. > > I think he is suggesting that you assign different IP addresses to the > same hostname, but one in the DNS server for corporate network A and the > other in the DNS server for corporate network B. That's what I thought of, but I think he has a people rather than technical problem here .. It would be trivial to set up an single domain on DNS servers for both LANs, but from what he's said about not being able to change the network I don't think that would happen. i.e. anything outside bugzilla itself is outside his control. Best advice could well be to leave the nasty hack in place and shout out respective network admins until they provide an address that works on both networks, or set up suitable DNS.. which if he can do it successfully would make a nice scenario to discuss in his next job interview when he finds somewhere with network managers who care about business needs ;) A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From lpsolit at gmail.com Fri May 11 14:12:11 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 11 May 2007 16:12:11 +0200 Subject: Bugzilla meeting next Tuesday (May 15) Message-ID: <464479BB.1070406@gmail.com> Hi all! We have a Bugzilla meeting next Tuesday, May 15 at 11:00 PST (20:00 CEST, 18:00 GMT). We will of course talk about the recent release of Bugzilla 3.0. But that's not all, see the agenda (in which you are free to add new suggestions) at http://wiki.mozilla.org/Bugzilla:Meetings As you probably know, our last meeting was on March 20, almost 2 months ago (nobody could attend last month, that's why), so we expect to have some interesting news (and stats! <-- justdave :)) to hear. See you on Tuesday in irc://irc.mozilla.org/bugzilla-meeting. As usual, the meeting is public; everyone is welcome! LpSolit From chicks at chicks.net Fri May 11 16:46:10 2007 From: chicks at chicks.net (Christopher Hicks) Date: Fri, 11 May 2007 12:46:10 -0400 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4643326E.5080208@inria.fr> References: <20070503003115.DFF301817A@help.trusthosting.net> <4643326E.5080208@inria.fr> Message-ID: <20070511164610.GD5586@chicks.net> On Thu, May 10, 2007 at 04:55:42PM +0200, Guillaume Rousse wrote: > Establish a standard perltidy configuration file. And use a dedicated > framework to impose your prefered style, such as Perl::Critic. Definitely a good plan for any perl project. > I recommand reading 'Perl Best Practices', > by D. Conway, for instance. Or even joining some perl conference to > present bugzilla, and discuss those issues directly with people. Damian Conway consitently exceeds my expectations and Perl Best Practices is a great example. I've been using Perl for 15 years or so, I teach perl classes, and all of the code we develop for clients is in Perl. We've had a Perl Style Guide internally for five or six years. And I still learned a lot from Perl Best Practices. I can't say that I agree with every bit of it and there are small parts of it that we note in our style guide as being in disagreement with Perl Best Practices, but the rest of the book is so self evidently a good idea its hard not to recommend it for anyone writing a script larger than 10 lines. Mr. Rousse deserves an ovation for his patience and directness in addressing what is a very suprising attitude from one of the core devs on one of the preeminent Perl applications in the world. Thanks Guillaume. -- "The problem with troubleshooting is that trouble shoots back!" From jwedoff at akamai.com Fri May 11 18:10:41 2007 From: jwedoff at akamai.com (John Wedoff) Date: Fri, 11 May 2007 11:10:41 -0700 Subject: Dynamic parameters In-Reply-To: References: Message-ID: <4644B1A1.8040605@akamai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 *I'd* certainly love to have something like that. - -John Wedoff Jochen Wiedmann wrote: > Hi, > > I have a use case, which I'd like to discuss here. > > I've got a Bugzilla installation, which is located between two > networks. In other words, it has two IP addresses. That's not unusual, > but unfortunately noth IP addresses are unreachable from the > respective other network. (This cannot be changed: The machine is > sitting between two large corporate networks and I do not have any > influence on the routing.) > > In other words, I am forced to change the "urlbase" parameter, > depending on the clients IP address. Currently I do that by hacking > Bugzill::Config->Param with a regexp of > > s/^([^\:]+\:\/\/)([\w\.\-]+)(.*)/$1$ENV{'SERVER_NAME'}$3/ > > I wonder whether I am the only one with a similar use case. Are there > any hooks in Bugzilla, which would allow me to remove my ugly hack? Or > would `such a hook be a valuable contribution? > > Thanks, > > Jochen > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGRLGhHQmr+6W89BURAnKwAKCNCc9XBV8NbUyEsqPLbvFuBEsQqQCgjbQw WRNDps66/2e6AXiL71TMcSg= =fpMa -----END PGP SIGNATURE----- From myk at mozilla.org Fri May 11 19:06:07 2007 From: myk at mozilla.org (Myk Melez) Date: Fri, 11 May 2007 12:06:07 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070503003115.DFF301817A@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> Message-ID: <4644BE9F.60409@mozilla.org> Folks seem to generally want to stick with Perl, which is not surprising given that Perl-friendly programmers are more likely to be attracted to a Perl-based project. But I'll throw in my .02 and say that I think Max is right about the language. Although it has many features to commend it and some elegant design, it also burdens programmers with overcomplicated syntax and provides too much enticement to poor programming practice. Of course it's possible to write good Perl code (and bad code in other languages), and one can always mitigate some of the problems with style guides, review, etc., but those mitigations are themselves costly. Either way, Perl imposes a productivity tax, and I'm much happier these days programming in other languages that have taken advantage of the last dozen or so years of research into language design (as Perl is still struggling to do with its next version). Nevertheless, it's still hard to decide to switch languages. Rewrites are expensive and risky, and they often fail (cf. the original Bugzilla 3.0). Plus, developments like the growth in browser-based logic, third-party extensions, and API clients may make the difficulties of hacking the core code less significant. So I'd first look for intermediate steps that would improve support for extending Bugzilla using other languages (perhaps the way Thrift does it) and then see if there's any way to use that to support incremental reimplementation. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From gupta at zeesource.net Sat May 12 01:22:08 2007 From: gupta at zeesource.net (Raj Gupta) Date: Fri, 11 May 2007 18:22:08 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4644BE9F.60409@mozilla.org> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> Message-ID: <753FF38A-19A9-4305-8E11-CD61317A4209@zeesource.net> I also want to add my 0.02 in this discussion. Several organizations customize and change Bugzilla code to suit their requirements. We have done some such changes for our clients. This is one of the big advantages of Open Source projects--you can customize and change code to suit your situation. Currently, such changes are relatively easily folded in to newer versions of Bugzilla, as the language and framework of Bugzilla remains fairly stable. In case the language and framework is changed, think of how many organizations may be stuck with the versions that they have, unless they make major re-investments in changing code in the new language! Regards Raj On May 11, 2007, at 12:06 PM, Myk Melez wrote: > Folks seem to generally want to stick with Perl, which is not > surprising given that Perl-friendly programmers are more likely to > be attracted to a Perl-based project. > > But I'll throw in my .02 and say that I think Max is right about > the language. Although it has many features to commend it and some > elegant design, it also burdens programmers with overcomplicated > syntax and provides too much enticement to poor programming practice. > > Of course it's possible to write good Perl code (and bad code in > other languages), and one can always mitigate some of the problems > with style guides, review, etc., but those mitigations are > themselves costly. > > Either way, Perl imposes a productivity tax, and I'm much happier > these days programming in other languages that have taken advantage > of the last dozen or so years of research into language design (as > Perl is still struggling to do with its next version). > > Nevertheless, it's still hard to decide to switch languages. > Rewrites are expensive and risky, and they often fail (cf. the > original Bugzilla 3.0). Plus, developments like the growth in > browser-based logic, third-party extensions, and API clients may > make the difficulties of hacking the core code less significant. > > So I'd first look for intermediate steps that would improve support > for extending Bugzilla using other languages (perhaps the way > Thrift does it) and then see if there's any way to use that to > support incremental reimplementation. > > -myk > -- Raj Gupta gupta at zeesource.net 1684 Nightingale Avenue Suite 201 Sunnyvale, CA 94087 408-733-2737(fax) http://www.zeesource.net From aaron.trevena at gmail.com Sat May 12 10:08:02 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sat, 12 May 2007 11:08:02 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4644BE9F.60409@mozilla.org> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> Message-ID: On 11/05/07, Myk Melez wrote: > > Folks seem to generally want to stick with Perl, which is not surprising > given that Perl-friendly programmers are more likely to be attracted to a > Perl-based project. User's don't care about what language is used, developers, rightly, tend to stick to languages they know and like, hardly a bad thing. > But I'll throw in my .02 and say that I think Max is right about the > language. Although it has many features to commend it and some elegant > design, it also burdens programmers with overcomplicated syntax and provides > too much enticement to poor programming practice. That's funny because I'd wager I write more and know more about Perl than either of you, and I disagree. Max and your criticisms of Perl thus far have been entirely subjective, looking at the pros and cons wiki page, it is pretty clear that switching to Python or Ruby would bring very real technical problems to the project, not to mention the social problems involved in forking and alienating both users and developers. > Of course it's possible to write good Perl code (and bad code in other > languages), and one can always mitigate some of the problems with style > guides, review, etc., but those mitigations are themselves costly. IME that isn't true. Mitigating for Python's poor error reporting, Ruby's poor performance and or reinventing wheels in Ruby are costly. > Either way, Perl imposes a productivity tax, and I'm much happier these > days programming in other languages that have taken advantage of the last > dozen or so years of research into language design (as Perl is still > struggling to do with its next version). That's nice for you. Like I said, your and max's feelings are purely subjective, I think Python imposes a huge productivity tax, what with linespace sensitivity and poor error reporting, but I know that's mostly subjective and don't go badgering Python projects to switch to perl, or trolling on slashdot/digg/reddit/etc as Python fanboys tend to. If you'd been paying attention, you'd see that Perl 6 features have been backported to Perl 5 both in CPAN and Core. Perl 5 is under very active development - have you seen the changelogs for 5.10? The next version of Perl is 5.10. It's a couple of weeks away. Perl 6 and Parrot development have been driving some recent development of Perl 5 in not only CPAN space but also the compiler and language. > Nevertheless, it's still hard to decide to switch languages. Rewrites are > expensive and risky, and they often fail (cf. the original Bugzilla 3.0). > Plus, developments like the growth in browser-based logic, third-party > extensions, and API clients may make the difficulties of hacking the core > code less significant. Yup. Call me crazy, but how about focusing on using contempory Perl and looking at genuine technical problems instead subjective 'grass is greener' whining. After so many years I'm pretty surprised that none of the bugzilla developers have worked on something to make bundling CPAN modules easier, or even used anything like PAR - every wheel seems to be reinvented. I'm also surprised that there is no pagination for results, and that every result for a query - even if there are thousands are always fetched and loaded into tons of hashes - no wonder it's memory hungry if you write code that eats memory like candy. I spoke to Max about solving this latter problem, and I'm still interested in doing so, but to be honest the combination of the Mozilla Foundation/Corporation leaving the project to rot with no funding or support, so much crufty out of date code and a couple of vocal people clamouring to stop useful development and instead switch to more fashionable languages makes me think "stuff it, it's easier to use rt or trac than put up with that". If anybody is actually interested in some constructive feedback on what needs doing to improve the bugzilla project, that's fine, but I'm not going to waste my time, when people who make money from bugzilla are wasting there's rewriting it poorly in a language that makes them feel warm and fuzzy. cheers, A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From justdave at bugzilla.org Sat May 12 13:27:00 2007 From: justdave at bugzilla.org (David Miller) Date: Sat, 12 May 2007 09:27:00 -0400 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> Message-ID: <4645C0A4.9020806@bugzilla.org> Aaron Trevena wrote on 5/12/07 6:08 AM: > After so many years I'm pretty surprised that none of the bugzilla > developers have worked on something to make bundling CPAN modules > easier, or even used anything like PAR - every wheel seems to be > reinvented. This is mostly in response to complaints from people trying to install Bugzilla. Our end-users seem to detest external dependencies, so we always have to evaluate how much bang we're getting out of a perl module before adding it, and if it's a wheel that's ridiculously easy to reinvent, we probably will, to avoid the dependency. If it's a mature module with lots of bang for the effort (it will actually save us a lot of time writing code) then we'll probably use it. > I'm also surprised that there is no pagination for results, and that > every result for a query - even if there are thousands are always > fetched and loaded into tons of hashes - no wonder it's memory hungry > if you write code that eats memory like candy. Yeah, there's times when you actually want all of them at once, but it shouldn't be the default. > I spoke to Max about solving this latter problem, and I'm still > interested in doing so, but to be honest the combination of the > Mozilla Foundation/Corporation leaving the project to rot with no > funding or support, so much crufty out of date code and a couple of > vocal people clamouring to stop useful development and instead switch > to more fashionable languages makes me think "stuff it, it's easier to > use rt or trac than put up with that". Given the discussion that's happened here so far I think it's extremely unlikely that Bugzilla will switch to a new language, at least for the core code. I think the discussion is worth having because its a critical analysis of our code and it helps us understand the code better and points out some things we need to pay attention to, but I don't see the project moving to a new language anytime soon. > If anybody is actually interested in some constructive feedback on > what needs doing to improve the bugzilla project, that's fine, but I'm > not going to waste my time, when people who make money from bugzilla > are wasting there's rewriting it poorly in a language that makes them > feel warm and fuzzy. I tend to agree with you here. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Sat May 12 14:15:53 2007 From: justdave at bugzilla.org (David Miller) Date: Sat, 12 May 2007 10:15:53 -0400 Subject: Bugzilla in the news Message-ID: <4645CC19.7080407@bugzilla.org> As of 7am Pacific, Saturday May 12: "Bugzilla 3.0 let loose upon the world" - srlinuxx http://www.tuxmachines.org/node/16205 "Bugzilla 3.0 let loose upon the world" - Staff Writer http://www.tectonic.co.za/view.php?id=1505 "More Bugs Quashed With Bugzilla 3.0" - Sean Michael Kerner http://www.internetnews.com/dev-news/article.php/3677011 "More Bugs Quashed With Bugzilla 3.0" - tk421 http://mobile.newsforge.com/newsvac/07/05/10/2148203.shtml "Bugzilla 3.0 Released" - no byline http://www.mozillazine.org/talkback.html?article=21713 "After 9 years, Bugzilla moves up to 3.0" - Mayank Sharma http://www.linux.com/article.pl?sid=07/05/12/0234203 "After 9 years, Bugzilla moves up to 3.0" - Mayank Sharma http://trends.newsforge.com/trends/07/05/12/0233209.shtml "After 9 Years, Bugzilla Moves Up to 3.0" - Zonk / BuggyUser http://it.slashdot.org/article.pl?sid=07/05/12/0641225 "Bugzilla 3.0 Released!" - zbraniecki http://digg.com/software/Bugzilla_3_0_released "After NINE YEARS, Bugzilla moves up to 3.0 !" - estvir http://digg.com/linux_unix/After_NINE_YEARS_Bugzilla_moves_up_to_3_0 "Why did it take bugzilla 9 years to get from version 2.0 to 3.0? - stu42j http://digg.com/linux_unix/Why_did_it_take_Bugzilla_9_years_to_get_from_version_2_0_to_3_0 "More Bugs Quashed With Bugzilla 3.0" - Sean Michael Kerner http://www.linuxtoday.com/news_story.php3?ltsn=2007-05-11-018-35-OS-SW-DV -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From aaron.trevena at gmail.com Sat May 12 14:20:30 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sat, 12 May 2007 15:20:30 +0100 Subject: Pagination and efficiency Message-ID: Hi all, After getting that rant off my chest hopefully we can move onto discussing useful things :) Private conversation with Max follows, as I'd like to move it forward on the list, and maybe start sending patches and fixing stuff. >> Aaron : >> I had a look at Bugzilla::Search and adding pagination should be >> trivial - either by lifting a bunch of code from Data::Pager and >> Maypole's templates, or by using the cpan module as is. Which brings >> me to my next question.. presumably there is cookie for storing >> session info in? > Max : > You could just make a new cookie for this particular session > information. There is the Bugzilla_user (I think that's its name) > cookie that handles session-based auth. >> That could be useful in the case where we don't want >> to repeatedly fetch every result from the db, but do want to know how >> many results there are.. so the first query would not use a limit, but >> only the first X records will be fetched, thereafter offset and limit >> can be used, and the total number of results stored in a session or >> something (with some simple bounds checking). > Yeah, perhaps. We should also consider the problems with a > result set changing underneath us, though. That would be the same problem as the current one of the entire result set being retrieved in one go, in fact it would improve, as each page would be up to date, and the pagination can easily handle coping if there are extra results fetched at the end. The number of results/pages won't change much as people page through, and can always be updated by fetching everything if the last result was 'old'. >> My other thoughts about efficiency make me think you could lose a lot >> of the hashes, by populating an iterator with fetchall_arrayref, and >> using array based objects instead of hashes. > I'm not sure the efficiency there would make up for the added > inconvenience. We do use the object hashes to store non-DB data, also. I don't there would be any inconvenience - in fact switching to using objects to represent data fetched from the db (even if they are simple read-only blessed pseudohash) would provide a facade allowing you to use any type of object, such as RoseDB, DBIx::Class or CDBI later without having to change much code. The Class::DBI Iterator is fairly simple, and I believe I could create something very simple based on it for bugzilla - again this would provide a facade allowing you to use any similar iterators provided by an ORM later. >> You could also use >> Tree::Binary::Dictionary for all the smaller hashes, and reduce the >> size of the over-all hash space, and so save some memory. > I haven't seen Tree::Binary::Dictionary, but that could help. buglist appears to use a bunch of hashes that could contain anything between a few and a few thousand entries, using slices of results or an iterator would mean that bunch of hashes could each be small enough to be replaced with Binary::Tree::Dictionary objects without loss of performance, while reducing the need for memory. >> Contrary to popular belief you *can* have a long running perl process >> that doesn't hog memory - my scheduler is written in perl and runs for >> weeks, never going above 30 MB, despite dealing with 000s of objects >> and being 10s of 000s of LoC (excluding the framework and modules it >> uses). regards, A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From chicks at chicks.net Sat May 12 19:00:05 2007 From: chicks at chicks.net (Christopher Hicks) Date: Sat, 12 May 2007 15:00:05 -0400 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4645C0A4.9020806@bugzilla.org> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <4645C0A4.9020806@bugzilla.org> Message-ID: <20070512190005.GA27348@chicks.net> On Sat, May 12, 2007 at 09:27:00AM -0400, David Miller wrote: > Our end-users seem to detest external dependencies, so we > always have to evaluate how much bang we're getting out of a perl module > before adding it, and if it's a wheel that's ridiculously easy to > reinvent, we probably will, to avoid the dependency. If it's a mature > module with lots of bang for the effort (it will actually save us a lot > of time writing code) then we'll probably use it. Why make the end user pay the tax? Package all the modules we need with the bugzilla distro. This is how Krang and Twiki operate to varying degrees. Whining about the failures of Perl's module system when we're not doing what works well for other groups shipping Perl web applications seems a bit strange to me. I'm not sure what scripts and tools krang and twiki use to maintain their own lib trees, but it can't be harder to write than dealing with all of the end user complaints. -- "The problem with troubleshooting is that trouble shoots back!" From jochen.wiedmann at gmail.com Sat May 12 19:16:45 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Sat, 12 May 2007 21:16:45 +0200 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4645C0A4.9020806@bugzilla.org> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <4645C0A4.9020806@bugzilla.org> Message-ID: On 5/12/07, David Miller wrote: > Bugzilla. Our end-users seem to detest external dependencies, so we > always have to evaluate how much bang we're getting out of a perl module > before adding it, If so, then I really wonder about the rationale to replace the old framework for sending mails (as used in 2.22) with the new framework. I fail to see the advantage, but I clearly do see the disadvantage with the approximately 20 or so different modules for the simple purpose of sending mail. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From mkanat at bugzilla.org Sat May 12 19:40:11 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 12 May 2007 12:40:11 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> Message-ID: <20070512194140.F1AF4118031@help.trusthosting.net> On Sat, 12 May 2007 11:08:02 +0100 "Aaron Trevena" wrote: > looking at the pros and cons wiki page, it is pretty clear > that switching to Python or Ruby would bring very real technical > problems to the project, not to mention the social problems involved > in forking and alienating both users and developers. Hi Aaron. I believe we've talked and you've never written extensively in Python or Ruby, correct? > IME that isn't true. Mitigating for Python's poor error reporting, > Ruby's poor performance and or reinventing wheels in Ruby are costly. Which you have no extensive personal experience with, right? > I think Python imposes a huge productivity tax, what with > linespace sensitivity and poor error reporting, but I know that's > mostly subjective and don't go badgering Python projects to switch to > perl, or trolling on slashdot/digg/reddit/etc as Python fanboys tend > to. That is partly subjective. It's a matter of how fast the average person who doesn't know the language can become proficient in it, which will then also determine how quickly a user can become proficient in it. And I mean proficient enough to write correct, OO code by current best practices for that language. > The next version of Perl is 5.10. It's a couple of weeks away. Perl 5.8 was released in July 2002. Perl 5.10 will be released by about June 2007, according to this. I understand that the language internals are old, and that's one reason that Perl 6 is being written. (Instead of refactoring Perl 5.) In 2002, Python was at 2.1. In 2007 it's at 2.5. (That's four major releases.) Ruby unfortunately progresses at only about 1.5 times the rate of Perl development. (It's had one major release, 1.8, in the same time frame, and 1.9 should be out Some Time Soon.) So it doesn't have much advantage there. I think even Java has had several major releases since 2002. > Call me crazy, but how about focusing on using contempory Perl and > looking at genuine technical problems instead subjective 'grass is > greener' whining. That's also under consideration, if you read the Wiki page. > the combination of the > Mozilla Foundation/Corporation leaving the project to rot with no > funding or support, What? The Foundation has never sponsored the development of Bugzilla. > so much crufty out of date code There's certainly enough of that left. :-) > and a couple of vocal people clamouring to stop useful development Nobody said anything about stopping development. In fact, I even pointed out that that shouldn't happen. > wasting there's rewriting it poorly in a language that makes them > feel warm and fuzzy. Nobody's re-writing it yet. It's just research into whether or not there would be advantages. I'm glad to have your opinions on the subject. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Sat May 12 19:42:18 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 12 May 2007 12:42:18 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <4645C0A4.9020806@bugzilla.org> Message-ID: <20070512194347.ACD9F118031@help.trusthosting.net> On Sat, 12 May 2007 21:16:45 +0200 "Jochen Wiedmann" wrote: > If so, then I really wonder about the rationale to replace the old > framework for sending mails (as used in 2.22) with the new framework. > I fail to see the advantage, but I clearly do see the disadvantage > with the approximately 20 or so different modules for the simple > purpose of sending mail. Hi Jochen. The new Email:: modules have a much simpler and more flexible API, and they also offer much better error reporting (which was the primary reason we switched). "undef error at line X in Carp" is usually unhelpful (one of Mail::Mailer's standard errors). They also have much better APIs for parsing mails in However, I agree with you that the number of modules it brings in as dependencies is a problem. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Sat May 12 20:06:03 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 12 May 2007 13:06:03 -0700 Subject: Pagination and efficiency In-Reply-To: References: Message-ID: <20070512200732.94E20118031@help.trusthosting.net> On Sat, 12 May 2007 15:20:30 +0100 "Aaron Trevena" wrote: > I don't there would be any inconvenience - in fact switching to using > objects to represent data fetched from the db (even if they are simple > read-only blessed pseudohash) would provide a facade allowing you to > use any type of object, such as RoseDB, DBIx::Class or CDBI later > without having to change much code. Yes, I've long planned to do exactly that. :-) Actually, all that has to be done there is to make Bugzilla::Bug->new_from_list work (which isn't a big task) and then do whatever work in Search.pm and its consumers need to return and use Bugzilla::Bug objects. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jochen.wiedmann at gmail.com Sat May 12 21:40:36 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Sat, 12 May 2007 23:40:36 +0200 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070512194140.F1AF4118031@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <20070512194140.F1AF4118031@help.trusthosting.net> Message-ID: On 5/12/07, Max Kanat-Alexander wrote: > Nobody's re-writing it yet. It's just research into whether or > not there would be advantages. And, in fact, I wonder why you are considering a rewrite: Why not simply pushing Scarab? IMO, it was created out of rather similar considerations? Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From mkanat at bugzilla.org Sat May 12 23:56:40 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 12 May 2007 16:56:40 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <20070512194140.F1AF4118031@help.trusthosting.net> Message-ID: <20070512235809.5710B118031@help.trusthosting.net> On Sat, 12 May 2007 23:40:36 +0200 "Jochen Wiedmann" wrote: > And, in fact, I wonder why you are considering a rewrite: I'm not considering a re-write, really. If you read the original email (or blog post), you'll see that the first idea was to see if it was possible to move to another language incrementally. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jochen.wiedmann at gmail.com Sun May 13 00:23:07 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Sun, 13 May 2007 02:23:07 +0200 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070512235809.5710B118031@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <20070512194140.F1AF4118031@help.trusthosting.net> <20070512235809.5710B118031@help.trusthosting.net> Message-ID: On 5/13/07, Max Kanat-Alexander wrote: > I'm not considering a re-write, really. If you read the original > email (or blog post), you'll see that the first idea was to see if it > was possible to move to another language incrementally. I must admit, that I can hardly imagine that to be practical. You'd force the developers to live in two worlds. That would hardly attract fresh blood und frustrate the existing guys. Rather than harvesting the (whatever) advantages of another language, you'd buy the disadvantages and problems of a second. Instead of concentrating on functional tasks, you'd be busy to implement a framework for merging two worlds. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From myk at mozilla.org Sat May 12 15:49:13 2007 From: myk at mozilla.org (Myk Melez) Date: Sat, 12 May 2007 08:49:13 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4645C0A4.9020806@bugzilla.org> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <4645C0A4.9020806@bugzilla.org> Message-ID: <4645E1F9.2040503@mozilla.org> David Miller wrote: > Aaron Trevena wrote on 5/12/07 6:08 AM: > >> I'm also surprised that there is no pagination for results, and that >> every result for a query - even if there are thousands are always >> fetched and loaded into tons of hashes - no wonder it's memory hungry >> if you write code that eats memory like candy. >> > > Yeah, there's times when you actually want all of them at once, but it > shouldn't be the default. > For me those times approach 100%, and I suspect most Bugzilla users (and many users of other applications that page information, often to increase ad views) feel the same, in which case paging bug lists by default would be a big step backwards. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From myk at mozilla.org Sun May 13 01:37:35 2007 From: myk at mozilla.org (Myk Melez) Date: Sat, 12 May 2007 18:37:35 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> Message-ID: <46466BDF.7040700@mozilla.org> Aaron Trevena wrote: > Like I said, your and max's feelings are purely subjective, I think > Python imposes a huge productivity tax, what with linespace > sensitivity and poor error reporting, but I know that's mostly > subjective and don't go badgering Python projects to switch to perl, > or trolling on slashdot/digg/reddit/etc as Python fanboys tend to. And yet this message contains sarcasm, misrepresentation, and ad-hominem attacks, i.e. trolling. If you'd like to discuss the issue, I'd welcome your participation, but please do so reasonably and substantively. -myk From aaron.trevena at gmail.com Sun May 13 03:09:20 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sun, 13 May 2007 04:09:20 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <20070512194140.F1AF4118031@help.trusthosting.net> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <20070512194140.F1AF4118031@help.trusthosting.net> Message-ID: On 12/05/07, Max Kanat-Alexander wrote: > On Sat, 12 May 2007 11:08:02 +0100 "Aaron Trevena" > wrote: > > looking at the pros and cons wiki page, it is pretty clear > > that switching to Python or Ruby would bring very real technical > > problems to the project, not to mention the social problems involved > > in forking and alienating both users and developers. > > Hi Aaron. I believe we've talked and you've never written > extensively in Python or Ruby, correct? True. But that doesn't mean I haven't experienced technical issues with it - in the last couple of months I've tried to install several python applications - the error reporting was surprisingly poor "Syntax error at line XXX", > > IME that isn't true. Mitigating for Python's poor error reporting, > > Ruby's poor performance and or reinventing wheels in Ruby are costly. > > Which you have no extensive personal experience with, right? See above. > > The next version of Perl is 5.10. It's a couple of weeks away. > > Perl 5.8 was released in July 2002. > > Perl 5.10 will be released by about June 2007, according to > this. I understand that the language internals are old, and that's one > reason that Perl 6 is being written. (Instead of refactoring Perl 5.) > > In 2002, Python was at 2.1. In 2007 it's at 2.5. (That's four > major releases.) That's a double edged sword - having to upgrade python because you need a newer version of a library sucks. I've never yet had to upgrade Perl because a library depends on a newer version, but I've been unable to install several python applications for this reason. I don't see any real benefit to lots of releases of a compiler unless there are lots of bugs to fix, or it's immature and needs new features, etc. > I think even Java has had several major releases since 2002. Yes and they aren't all 100% compatible. Moving goalposts with changing API's, nice. > > Call me crazy, but how about focusing on using contempory Perl and > > looking at genuine technical problems instead subjective 'grass is > > greener' whining. > > That's also under consideration, if you read the Wiki page. Not really - Catalyst is mentioned, but that's about it. > > the combination of the > > Mozilla Foundation/Corporation leaving the project to rot with no > > funding or support, > > What? The Foundation has never sponsored the development of > Bugzilla. Which is sucky. Mozilla Corp makes 10s of millions of dollars. Bugzilla is a Mozilla project, used heavily by other mozilla projects. > > and a couple of vocal people clamouring to stop useful development > > Nobody said anything about stopping development. In fact, I > even pointed out that that shouldn't happen. I take that back then :) > > wasting there's rewriting it poorly in a language that makes them > > feel warm and fuzzy. > > Nobody's re-writing it yet. It's just research into whether or > not there would be advantages. I'm glad to have your opinions on the > subject. I think that's looking at the wrong problem, IMHO. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From aaron.trevena at gmail.com Sun May 13 03:14:48 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sun, 13 May 2007 04:14:48 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <46466BDF.7040700@mozilla.org> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <46466BDF.7040700@mozilla.org> Message-ID: On 13/05/07, Myk Melez wrote: > Aaron Trevena wrote: > > Like I said, your and max's feelings are purely subjective, I think > > Python imposes a huge productivity tax, what with linespace > > sensitivity and poor error reporting, but I know that's mostly > > subjective and don't go badgering Python projects to switch to perl, > > or trolling on slashdot/digg/reddit/etc as Python fanboys tend to. > And yet this message contains sarcasm, misrepresentation, and ad-hominem > attacks, i.e. trolling. If you'd like to discuss the issue, I'd welcome > your participation, but please do so reasonably and substantively. Nothing I said there was sarcastic. My dislike is of python is 100% subjective, it has it's flaws but so does every language. My dislike of python zealots is based on exactly what I see on /. etc - Max posted his rant about Perl and how much better python would be to LJ and that was submitted (by somebody else) to digg/reddit and picked up by said zealots on slashdot. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From Nick.Barnes at pobox.com Sun May 13 13:02:18 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Sun, 13 May 2007 14:02:18 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: from "Aaron Trevena" of "Sat, 12 May 2007 11:08:02 +0100" Message-ID: <52470.1179061338@thrush.ravenbrook.com> At 2007-05-12 10:08:02+0000, "Aaron Trevena" writes: > IME that isn't true. Mitigating for Python's poor error reporting, > Ruby's poor performance and or reinventing wheels in Ruby are costly. A number of people have mentioned the quality of error reporting as a strike against Python. Can any of these people provide a concrete example of what they are talking about? With source code, and a misleading or confusing error message? I've never had any problem understanding or using Python error messages. They're much like Perl errors: you get an error message, a code location, and a backtrace. Sometimes one wants a little more information in order to make a full diagnosis, so for one Python project I wrote a tiny utility to get backtraces with local variable values, which I can then print out and put in the application log file: The fact that I develop most of my Python with a command line to hand, in which I can type pdb.pm() at any point to grovel around the code and data with the debugger, makes Python errors very much easier for me to deal with than Perl ones. I dare say there are command line tools analogous to this, built in to Perl, but I've never found them. Nick B From aaron.trevena at gmail.com Sun May 13 15:24:35 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sun, 13 May 2007 16:24:35 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <52470.1179061338@thrush.ravenbrook.com> References: <52470.1179061338@thrush.ravenbrook.com> Message-ID: On 13/05/07, Nick Barnes wrote: > At 2007-05-12 10:08:02+0000, "Aaron Trevena" writes: > > > IME that isn't true. Mitigating for Python's poor error reporting, > > Ruby's poor performance and or reinventing wheels in Ruby are costly. > > A number of people have mentioned the quality of error reporting as a > strike against Python. Can any of these people provide a concrete > example of what they are talking about? With source code, and a > misleading or confusing error message? ...because I keep a file of such things to hand.. not ;) from memory : >> syntax error at Line XXX @common.something << > I've never had any problem understanding or using Python error > messages. They're much like Perl errors: you get an error message, a > code location, and a backtrace. Except in Perl I'll get a whole lot more, such as 'expected foo' or 'unexpected foo' or 'undeclared bar' or 'runaway quote at line xxx', and even warnings like '= in selection at line xx'. Perl will always give a good indication of what the error was in the syntax, python IME will not. as for debugging.. did you ever bother to are tee eff em? perldoc perldebug recommends reading perldoc perldebtut and gives the very simple example of : "perl -d -e 42" Kinda makes sense, perl -e do evaluate, perl -w to warn, perl -c to compile, so very arcane, not ;) A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From Nick.Barnes at pobox.com Sun May 13 17:23:11 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Sun, 13 May 2007 18:23:11 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: from "Aaron Trevena" of "Sun, 13 May 2007 16:24:35 +0100" Message-ID: <52828.1179076991@thrush.ravenbrook.com> At 2007-05-13 15:24:35+0000, "Aaron Trevena" writes: > On 13/05/07, Nick Barnes wrote: > > At 2007-05-12 10:08:02+0000, "Aaron Trevena" writes: > > > > > IME that isn't true. Mitigating for Python's poor error reporting, > > > Ruby's poor performance and or reinventing wheels in Ruby are costly. > > > > A number of people have mentioned the quality of error reporting as a > > strike against Python. Can any of these people provide a concrete > > example of what they are talking about? With source code, and a > > misleading or confusing error message? > > ...because I keep a file of such things to hand.. not ;) > > from memory : > >> > syntax error at Line XXX > @common.something > << OK, that's from your memory. Now this is from Python itself: $ $ python bugzilla.py File "bugzilla.py", line 46 def init(self, db, $config): ^ SyntaxError: invalid syntax $ What's unclear about that? Note the handy caret, indicating the offending character at which Python's lexer (understandably) barfs. I can't parse your "@common.something" line. Is that supposed to resemble part of a Python error message? > Except in Perl I'll get a whole lot more, such as 'expected foo' or > 'unexpected foo' or 'undeclared bar' or 'runaway quote at line xxx', Are these syntax errors? ('runaway quote' is, of course). Python, of course, has gloriously simple syntax, so syntax errors are fairly unusual in the first place, and are almost always trivial to fix. Other errors (e.g. runtime exceptions) are reported comprehensively in Python. Python certainly has many faults (for instance, I think that the indentation syntax is a mistake; also it doesn't have strong static typing, simple syntax for higher-order functions, or a type-safe module language). But error reporting really isn't one of them. And if we start discussing syntax errors in this thread, we are bound to end up in a discussion of syntax itself, and Perl fans might prefer to avoid that line of argument. Perl, by design, puts complex functionality into the syntax. Python, by design, keeps the syntax simple and consistent and puts functionality into library modules. > as for debugging.. did you ever bother to are tee eff em? Please try to be less offensive. Of course I've read the manual. Of course I've used perl -d. In fact I end up using this rather cranky tool every single time I write any code for Bugzilla, because getting the twisty Perl syntax correct, even for something trivial, takes me four or five attempts. My debugging print statements always break the parser on the first attempt, tell me that my variable is a HASH on the second attempt, reveal how many entries it contains on the third attempt, break the parser on the fourth attempt, and finally tell me the value that I'm after on the fifth or sixth attempt. That's if I get the funky string quotation/expression anti-quotation rules straight. Nick B From aaron.trevena at gmail.com Sun May 13 17:48:59 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sun, 13 May 2007 18:48:59 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <52828.1179076991@thrush.ravenbrook.com> References: <52828.1179076991@thrush.ravenbrook.com> Message-ID: On 13/05/07, Nick Barnes wrote: > At 2007-05-13 15:24:35+0000, "Aaron Trevena" writes: > > > > from memory : > > >> > > syntax error at Line XXX > > @common.something > > << > > OK, that's from your memory. Now this is from Python itself: > > $ > $ python bugzilla.py > File "bugzilla.py", line 46 > def init(self, db, $config): > ^ > SyntaxError: invalid syntax > $ > > What's unclear about that? Note the handy caret, indicating the > offending character at which Python's lexer (understandably) barfs. I > can't parse your "@common.something" line. Is that supposed to > resemble part of a Python error message? @common.threads is where this particular python application barfed. I didn't see anything obvious, otherwise I might have looked at it a bit more instead of finding something that didn't require upgrading or debugging to work. "Syntax Error : invalid syntax".. priceless *LOL* ... as opposed to valid syntax causing a syntax error? ;) > > Except in Perl I'll get a whole lot more, such as 'expected foo' or > > 'unexpected foo' or 'undeclared bar' or 'runaway quote at line xxx', > > Are these syntax errors? ('runaway quote' is, of course). Python, of > course, has gloriously simple syntax, so syntax errors are fairly > unusual in the first place, and are almost always trivial to fix. That's incredibly subjective. I find Python opaque, you find Perl not too difficult and not to your taste. > Other errors (e.g. runtime exceptions) are reported comprehensively in > Python. That's helpful, as compilation doesn't catch undeclared variables or whatever. > Python certainly has many faults (for instance, I think that the > indentation syntax is a mistake; also it doesn't have strong static > typing, simple syntax for higher-order functions, or a type-safe > module language). But error reporting really isn't one of them. And > if we start discussing syntax errors in this thread, we are bound to > end up in a discussion of syntax itself, and Perl fans might prefer to > avoid that line of argument. Perl, by design, puts complex > functionality into the syntax. Python, by design, keeps the syntax > simple and consistent and puts functionality into library modules. Again. Subjective. Perl is concise, flexible and powerful. I'm no smarter than the average guy, but I never found any problems with Perl's syntax and haven't found it confusing. I lilke Perl's syntax, you hate it - don't pretend this is technical when it's not. > > as for debugging.. did you ever bother to are tee eff em? > > Please try to be less offensive. Of course I've read the manual. Well you said you didn't know how to debug. Of > course I've used perl -d. In fact I end up using this rather cranky > tool every single time I write any code for Bugzilla, because getting > the twisty Perl syntax correct, even for something trivial, takes me > four or five attempts. Then try and learn the language properly - you can go to classes - really, it's quite simple to learn. Your problem sounds more like mine - I find Python so opaque and contrary to what I'm familar with from C based languages that I just don't bother - on the plus side I don't whine about it and slag it off on python project lists, and certainly don't reccomend people not to use it just because of my personal feelings towards how it does things. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From aaron.trevena at gmail.com Sun May 13 18:01:49 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sun, 13 May 2007 19:01:49 +0100 Subject: end to the language advocacy please Message-ID: Right, I was going to ask for svn commit access and try and sort some out the sorry mess that is bugzilla's codebase, but the Python 'advocates' have been busy spreading FUD and misinformation and generally making trouble, and I have better things to do than bicker about the subjective qualities of syntax and the various trade-offs that different language creators and users make. Anyway - assuming we've had enough of these totally pointless and unconstructive "discussions" I was rather hoping we could move on before I totally lose interest and port Trac to perl because it would probably be less work than sorting out bugzilla, and well, because I'd rather use perl than python (which I'm at least honest about). So - can somebody remove the pointless wiki page about language discussions before we drag yet more advocates and zealots from every language to flame and troll, as they inevitably do when ever you compare languages, and stop with the "Perl made me write bad code, you can't maintain or scale it" crap please. Thanks, A p.s. I'd still like a cvs commit account - maybe coding would help blot out the incessant whining from the python users on the list about how hard perl is. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From lpsolit at gmail.com Sun May 13 18:08:20 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sun, 13 May 2007 20:08:20 +0200 Subject: end to the language advocacy please In-Reply-To: References: Message-ID: <46475414.7010808@gmail.com> Aaron Trevena a ?crit : > p.s. I'd still like a cvs commit account You don't need CVS write access to post patches. We first ask contributors to... contribute a bit before letting them submit patches (which have to go through a review + approval process first before being committed). LpSolit From aaron.trevena at gmail.com Sun May 13 18:15:49 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sun, 13 May 2007 19:15:49 +0100 Subject: end to the language advocacy please In-Reply-To: <46475414.7010808@gmail.com> References: <46475414.7010808@gmail.com> Message-ID: On 13/05/07, Fr?d?ric Buclin wrote: > Aaron Trevena a ?crit : > > p.s. I'd still like a cvs commit account > > You don't need CVS write access to post patches. We first ask > contributors to... contribute a bit before letting them submit patches > (which have to go through a review + approval process first before being > committed). That seems like a lot of trouble for the ammount of work that needs to be done, and I'm not exactly impressed with the reviewers to be honest. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From mkanat at bugzilla.org Sun May 13 18:18:04 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 13 May 2007 11:18:04 -0700 Subject: end to the language advocacy please In-Reply-To: References: Message-ID: <20070513181934.4B2E3118034@help.trusthosting.net> On Sun, 13 May 2007 19:01:49 +0100 "Aaron Trevena" wrote: > I have better things to do than bicker about the > subjective qualities of syntax and the various trade-offs that > different language creators and users make. Then stay out of the conversation. It's just a conversation. People are allowed to have conversations. And you don't have to read them. Nor do you have to participate. > p.s. I'd still like a cvs commit account As LpSolit said, you just have to read our Contributor's Guide to know how to post a patch. I linked you to it a while ago by email. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Sun May 13 18:20:59 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 13 May 2007 11:20:59 -0700 Subject: end to the language advocacy please In-Reply-To: References: <46475414.7010808@gmail.com> Message-ID: <20070513182229.6F596118034@help.trusthosting.net> On Sun, 13 May 2007 19:15:49 +0100 "Aaron Trevena" wrote: > That seems like a lot of trouble for the ammount of work that needs to > be done, and I'm not exactly impressed with the reviewers to be > honest. Hi Aaron. If you plan to continue denigrating our developers, who work very hard and on a completely volunteer basis, then I would suggest you find another project to harass. Your *help* is certainly acceptable, but your personal criticisms are not. With that said, our review process exists for a very good reason, and is definitely necessary. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From aaron.trevena at gmail.com Sun May 13 18:28:19 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sun, 13 May 2007 19:28:19 +0100 Subject: end to the language advocacy please In-Reply-To: <20070513182229.6F596118034@help.trusthosting.net> References: <46475414.7010808@gmail.com> <20070513182229.6F596118034@help.trusthosting.net> Message-ID: On 13/05/07, Max Kanat-Alexander wrote: > On Sun, 13 May 2007 19:15:49 +0100 "Aaron Trevena" > wrote: > > That seems like a lot of trouble for the ammount of work that needs to > > be done, and I'm not exactly impressed with the reviewers to be > > honest. > > Hi Aaron. If you plan to continue denigrating our developers, > who work very hard and on a completely volunteer basis, then I would > suggest you find another project to harass. How can I be impressed when the guy doing the reviews rants about how much he hates perl and suggests using something else. That's not exactly encouraging - especially when he also suggests rewriting in a language he'd rather use. Bugzilla developers seem to have shunned the Perl community, failing to attract experienced Perl developers, and accumulating an umanaged and almost unmanagable codebase. > Your *help* is certainly acceptable, but your personal > criticisms are not. Well you complained about the viability of bugzilla in the future, I'm just pointing out that the problems are primarily non-technical in nature. > With that said, our review process exists for a very good > reason, and is definitely necessary. Well, I'll give it a go. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From lpsolit at gmail.com Sun May 13 18:43:24 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sun, 13 May 2007 20:43:24 +0200 Subject: end to the language advocacy please In-Reply-To: References: <46475414.7010808@gmail.com> <20070513182229.6F596118034@help.trusthosting.net> Message-ID: <46475C4C.50005@gmail.com> Aaron Trevena a ?crit : > How can I be impressed when the guy doing the reviews rants about how > much he hates perl and suggests using something else. For your information, Max is not the only reviewer, we are a dozen active ones. And what you are complaining about is only Max's opinion, not the one of the Bugzilla project. Moreover, as he repeated several times, he doesn't "hate" Perl. And as far as I know, he is free to prefer another language. This doesn't mean he will force us to move to another language. > Bugzilla developers seem to have shunned the Perl community, failing > to attract experienced Perl developers, and accumulating an umanaged > and almost unmanagable codebase. Again, you are talking about Bugzilla developers despite you know nothing about them and nothing about what they think. And our code is much more readable and usable than 2 years ago. I don't think your attitude is the correct one if you want us to collaborate. LpSolit From mkanat at bugzilla.org Sun May 13 18:47:05 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 13 May 2007 11:47:05 -0700 Subject: end to the language advocacy please In-Reply-To: References: <46475414.7010808@gmail.com> <20070513182229.6F596118034@help.trusthosting.net> Message-ID: <20070513184836.3FAD7118031@help.trusthosting.net> On Sun, 13 May 2007 19:28:19 +0100 "Aaron Trevena" wrote: > How can I be impressed when the guy doing the reviews rants about how > much he hates perl [snip] Rants? Hates? What? Did you read the blog? "Perl has many great features, most of all the number of libraries available and the extreme flexibility of the language." Aaron, apparently you can't stop attacking people personally no matter what, so until you acquire that ability, I'm not really interested in having you contribute further criticism. (Meaning that I'm not really interested in having you contribute at all.) We can talk this over in personal email, if you want. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From aaron.trevena at gmail.com Sun May 13 19:05:59 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Sun, 13 May 2007 20:05:59 +0100 Subject: end to the language advocacy please In-Reply-To: <46475C4C.50005@gmail.com> References: <46475414.7010808@gmail.com> <20070513182229.6F596118034@help.trusthosting.net> <46475C4C.50005@gmail.com> Message-ID: On 13/05/07, Fr?d?ric Buclin wrote: > Aaron Trevena a ?crit : > > How can I be impressed when the guy doing the reviews rants about how > > much he hates perl and suggests using something else. > > For your information, Max is not the only reviewer, we are a dozen > active ones. And what you are complaining about is only Max's opinion, > not the one of the Bugzilla project. Moreover, as he repeated several > times, he doesn't "hate" Perl. And as far as I know, he is free to > prefer another language. This doesn't mean he will force us to move to > another language. Then I've got a false impression from what I've seen Max say on the wiki and in his blog. The wiki discussion page says : ""I think everyone agrees that Perl5 is difficult for large, maintainable applications, and no one wants to advocate continuing to use it. " and his blog talks about how much better Ruby and Python would be, before giving a shopping list of pet hates, and another grocery list on the wiki, it looked like a rant to me. > > Bugzilla developers seem to have shunned the Perl community, failing > > to attract experienced Perl developers, and accumulating an umanaged > > and almost unmanagable codebase. > > Again, you are talking about Bugzilla developers despite you know > nothing about them and nothing about what they think. And our code is > much more readable and usable than 2 years ago. Mea Culpa - Max has just informed that the two places I was looking at haven't been touched since he arrived, so it shouldn't be surprising it looked so old and crufty. A -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From kevin.benton at amd.com Sun May 13 22:49:53 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Sun, 13 May 2007 15:49:53 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <52828.1179076991@thrush.ravenbrook.com> Message-ID: > > > as for debugging.. did you ever bother to are tee eff em? > > > > Please try to be less offensive. Of course I've read the manual. > > Well you said you didn't know how to debug. Aaron, go away. We don't need your kind of eff'ing rudeness. This is a very kind group and I have never seen anyone in the past 2.5 years treat the group as badly as I have seen you treat us in this thread. It's not called for and it certainly is not appreciated. I think you owe everyone in this group an apology but at this point, I'd rather you just go bother someone else. Kevin Benton MySQL DBA #5739 Senior Software Developer MSS Silicon Design Engineering Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From Nick.Barnes at pobox.com Mon May 14 00:12:06 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 14 May 2007 01:12:06 +0100 Subject: group_control_map.canconfirm and friends Message-ID: <53600.1179101526@thrush.ravenbrook.com> Dear all, but especially LpSolit and mkanat, Preparing updates to the online schema doc, I've been looking at the three columns added to the group_control_map table: editbugs, editcomponents, and canconfirm. This is from the patch by LpSolit, reviewed by mkanat, for bug 189627. If I'm reading the code correctly, these columns are used by in_group() in Bugzilla/User.pm. Using "editcomponents" as an example, in_group uses the columns to answer questions of the form "is user U entitled to edit the set of components for product P". A call is made: user->in_group('editcomponents', $product_id); If the user is in the global "editcomponents" group, this returns 1. Otherwise, if there is at least one group in group_control_map, for this product, which has group_control_map.editcomponents set, and of which this user is a member, it returns 1. Otherwise, it returns 0. There is also get_products_by_permission() in Bugzilla/User.pm. With the same 'editcomponents' example, this returns a list of the products which have a line in group_control_map with the editcomponents flag set, such that the user is in the group. Now, this indicates to me that (say) editcomponents privileges for a given product are given to everyone who is in *any* group with a suitable row in group_control_map, as opposed only to those people who are in *all* such groups. It's a union permission, in contrast to the intersection permissions which most of the groups system uses. While I don't have a working 3.0 installation, I can't tell whether editproducts.cgi lets me put more than one such row in group_control_map, but let's imagine that it did. Have I got this right? Was this the intended semantics? I've read the comment thread in 189627 but without much illumination on this question. Nick B From Nick.Barnes at pobox.com Mon May 14 00:22:48 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 14 May 2007 01:22:48 +0100 Subject: group_control_map.canconfirm and friends In-Reply-To: <53600.1179101526@thrush.ravenbrook.com> from Nick Barnes of "Mon, 14 May 2007 01:12:06 +0100" Message-ID: <53676.1179102168@thrush.ravenbrook.com> At 2007-05-14 00:12:06+0000, Nick Barnes writes: > Now, this indicates to me that (say) editcomponents privileges for a > given product are given to everyone who is in *any* group with a > suitable row in group_control_map, as opposed only to those people who > are in *all* such groups. It's a union permission, in contrast to the > intersection permissions which most of the groups system uses. In particular, I'm confused about the difference between the 'canedit' and 'editbugs' columns of group_control_map. Why are both of these columns needed? Where does each one get tested in the code when editing a bug? And what are the semantics if either (or both) of them are set for multiple groups? Suppose I have a product with four rows in group_control_map for groups G1-G4. canedit editbugs G1 1 1 G2 1 0 G3 0 1 G4 0 0 What group memberships would a user require to make an edit to a bug in this product? It seems to me that she would need *both* G1 and G2 (because *all* 'canedit' groups are required). And then she wouldn't need G3 (because already having G1 she passes the *any* test for 'editbugs'). I'm going to bed now; it might all be clearer in the morning. Nick B From Nick.Barnes at pobox.com Mon May 14 00:31:15 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 14 May 2007 01:31:15 +0100 Subject: Online schema doc updated Message-ID: <53750.1179102675@thrush.ravenbrook.com> I have updated the online Bugzilla schema documentation: This now reflects the 3.0 schema (i.e. the changes made in 2.23.4). Corrections to me, please. Kudos to Perforce Inc for supporting the P4DTI project. Nick Barnes P4DTI Project Ravenbrook Limited From mkanat at bugzilla.org Mon May 14 03:58:56 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 13 May 2007 20:58:56 -0700 Subject: group_control_map.canconfirm and friends In-Reply-To: <53600.1179101526@thrush.ravenbrook.com> References: <53600.1179101526@thrush.ravenbrook.com> Message-ID: <20070514040023.25249118034@help.trusthosting.net> On Mon, 14 May 2007 01:12:06 +0100 Nick Barnes wrote: > Have I got this right? Was this the intended semantics? You are correct. :-) Yes, that was intended. -Max From mkanat at bugzilla.org Mon May 14 04:06:06 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 13 May 2007 21:06:06 -0700 Subject: group_control_map.canconfirm and friends In-Reply-To: <53676.1179102168@thrush.ravenbrook.com> References: <53676.1179102168@thrush.ravenbrook.com> Message-ID: <20070514040733.74D07118031@help.trusthosting.net> On Mon, 14 May 2007 01:22:48 +0100 Nick Barnes wrote: > In particular, I'm confused about the difference between the 'canedit' > and 'editbugs' columns of group_control_map. There is a global permission called "editbugs." If somebody has this permission, they CANNOT edit a "canedit" product unless they are in that group. If somebody does not have global editbugs, they can be given product-specific editbugs. That allows them to edit bugs in ONLY that product. So they're basically opposites of each other. -Max From Nick.Barnes at pobox.com Mon May 14 07:12:32 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 14 May 2007 08:12:32 +0100 Subject: group_control_map.canconfirm and friends In-Reply-To: <20070514040733.74D07118031@help.trusthosting.net> from Max Kanat-Alexander of "Sun, 13 May 2007 21:06:06 -0700" Message-ID: <54506.1179126752@thrush.ravenbrook.com> At 2007-05-14 04:06:06+0000, Max Kanat-Alexander writes: > On Mon, 14 May 2007 01:22:48 +0100 Nick Barnes > wrote: > > In particular, I'm confused about the difference between the 'canedit' > > and 'editbugs' columns of group_control_map. > > There is a global permission called "editbugs." If somebody has > this permission, they CANNOT edit a "canedit" product unless they are > in that group. So if a bug is in a product which has 'canedit' for groups G1 and G2, and 'editbugs' for groups G3 and G4, then in order to edit the bug, a user must be in: at least one of {editbugs, G3, G4} AND at least one of {G1, G2}. Is that right? Nick B From mkanat at bugzilla.org Mon May 14 07:33:15 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 14 May 2007 00:33:15 -0700 Subject: group_control_map.canconfirm and friends In-Reply-To: <54506.1179126752@thrush.ravenbrook.com> References: <54506.1179126752@thrush.ravenbrook.com> Message-ID: <20070514073446.67743118031@help.trusthosting.net> On Mon, 14 May 2007 08:12:32 +0100 Nick Barnes wrote: > So if a bug is in a product which has 'canedit' for groups G1 and G2, > and 'editbugs' for groups G3 and G4, then in order to edit the bug, a > user must be in: > > at least one of {editbugs, G3, G4} > AND > at least one of {G1, G2}. Close! At least of one {editbugs, G3, G4} AND Both G1 and G2. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From Nick.Barnes at pobox.com Mon May 14 08:10:00 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 14 May 2007 09:10:00 +0100 Subject: group_control_map.canconfirm and friends In-Reply-To: <20070514073446.67743118031@help.trusthosting.net> from Max Kanat-Alexander of "Mon, 14 May 2007 00:33:15 -0700" Message-ID: <54671.1179130200@thrush.ravenbrook.com> At 2007-05-14 07:33:15+0000, Max Kanat-Alexander writes: > On Mon, 14 May 2007 08:12:32 +0100 Nick Barnes > wrote: > > So if a bug is in a product which has 'canedit' for groups G1 and G2, > > and 'editbugs' for groups G3 and G4, then in order to edit the bug, a > > user must be in: > > > > at least one of {editbugs, G3, G4} > > AND > > at least one of {G1, G2}. > > Close! > > At least of one {editbugs, G3, G4} > AND > Both G1 and G2. Thank you. I have clarified the online schema doc. Nick B From Nick.Barnes at pobox.com Mon May 14 08:19:54 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 14 May 2007 09:19:54 +0100 Subject: end to the language advocacy please In-Reply-To: <20070513184836.3FAD7118031@help.trusthosting.net> from Max Kanat-Alexander of "Sun, 13 May 2007 11:47:05 -0700" Message-ID: <54744.1179130794@thrush.ravenbrook.com> At 2007-05-13 18:47:05+0000, Max Kanat-Alexander writes: > On Sun, 13 May 2007 19:28:19 +0100 "Aaron Trevena" > wrote: > > How can I be impressed when the guy doing the reviews rants about how > > much he hates perl [snip] > > Rants? Hates? What? Did you read the blog? > > "Perl has many great features, most of all the number of > libraries available and the extreme flexibility of the language." For the record, I also agree with this sentence. Nick B From aaron.trevena at gmail.com Mon May 14 10:35:56 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Mon, 14 May 2007 11:35:56 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <52828.1179076991@thrush.ravenbrook.com> Message-ID: On 13/05/07, Benton, Kevin wrote: > Aaron, go away. We don't need your kind of eff'ing rudeness. This is a > very kind group and I have never seen anyone in the past 2.5 years treat > the group as badly as I have seen you treat us in this thread. It's not > called for and it certainly is not appreciated. I think you owe > everyone in this group an apology but at this point, I'd rather you just > go bother someone else. Mea Culpa. Sorry. I think I've been too harsh on the developers, partly because the trolling on the wiki, max's blog, and even the list got on my nerves, and partly because I thought a well placed 'kick on the arse' would do some good. I noticed that the release manager and lead reviewer claimed on his blog that Bugzilla was doomed if they stuck with Perl, and containing a very subjective (and ill-informed) list of grievances. Then another bugzilla developer created a wiki with which to push the agenda, which quickly filled with trolls and flamebait, then more bugzilla developers claimed on the list that Perl was the problem and how life would be so much more wonderful using the vastly superior Ruby or Python. I've just tried to point out (sometimes in an ill-tempered or harsh manner, I'm afraid), that the problem is social rather than technical in nature, and the solution is to learn to write code better, rather than write the same bad code in a new language. I've also tried to say that the review process doesn't seem to have improved the quality of the code base very much. Using Template Toolkit was a great move, but there don't seem to have been any other big steps forward in the years since I last used and hacked bugzilla. I think the fact that so many developers and reviewers are sysadmins first and developers second, or don't use Perl as their primary language could be one of the reasons that the code quality has taken so long to improve, and am surprised that so many sysadmins haven't found a way to bundle or package CPAN modules in a way that works for bugzilla users. Anyway I'll STFU now and stick to posting patches from here on. A -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From gerv at mozilla.org Mon May 14 10:42:44 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 14 May 2007 11:42:44 +0100 Subject: Using Bugzilla to hide spam sites Message-ID: <46483D24.5010802@mozilla.org> Developers, I just had the below spam comment posted to my blog. It struck my eye because the URL is a Bugzilla attachment URL. Viewing it in "edit" mode: http://bugzilla.lyx.org/attachment.cgi?id=1638&action=edit shows that the spammer has attached a copy of their pills sale page. It turns out that it contains embedded obfuscated JS code which redirects you to the real thing if you visit the attachment. So they are using Bugzilla to avoid any domain blacklists in my blogging software. I'm not sure there's much we can do about this. The spammer obviously took time to create an account - perhaps automatically, perhaps not. Short of implementing Captchas for account signup, or refusing to display HTML attachments as HTML, I can't see a counter. Thoughts? Gerv -------- Original Message -------- Subject: [Hacking for Christ] New Comment Posted to 'More Times Articles' Date: Sat, 12 May 2007 18:58:53 +0000 (UTC) From: kzyumv at hotmail.com To: gerv at mozilla.org A new comment has been posted on your blog Hacking for Christ, on entry #10119 (More Times Articles). View this comment: Edit this comment: IP Address: 200.80.204.142 Name: buy online tramadol Email Address: kzyumv at hotmail.com URL: http://bugzilla.lyx.org/attachment.cgi?id=1638 Comments: Very good site. Thank you. http://bugzilla.lyx.org/attachment.cgi?id=1638 buy online tramadol -- Powered by Movable Type Version 3.32 http://www.sixapart.com/movabletype/ From wicked at etlicon.fi Mon May 14 11:14:15 2007 From: wicked at etlicon.fi (Teemu Mannermaa) Date: Mon, 14 May 2007 14:14:15 +0300 Subject: Using Bugzilla to hide spam sites In-Reply-To: <46483D24.5010802@mozilla.org> References: <46483D24.5010802@mozilla.org> Message-ID: <46484487.3030803@etlicon.fi> On 14.05.2007 13:43, Gervase Markham wrote: > I just had the below spam comment posted to my blog. It struck my eye > because the URL is a Bugzilla attachment URL. Yeah, I have seen this problem reported before. Bmo was just hit with such attachment a while ago (which justdave deleted promptly) and there was a bug opened about this issue. See https://bugzilla.mozilla.org/show_bug.cgi?id=380489 for details. > I'm not sure there's much we can do about this. The spammer obviously That was my thought exactly. I'm not sure what can be done about this issue short of preventing HTML attachments or start parsing and stripping bad code from them before showing. It does look like this problem is been exploited extensively. :( -- Teemu Mannermaa System Specialist "Anything is possible. It's all about probabilities." From julien.beti at free.fr Mon May 14 11:20:18 2007 From: julien.beti at free.fr (Julien BETI) Date: Mon, 14 May 2007 13:20:18 +0200 Subject: Using Bugzilla to hide spam sites In-Reply-To: <46484487.3030803@etlicon.fi> References: <46483D24.5010802@mozilla.org> <46484487.3030803@etlicon.fi> Message-ID: <464845F2.2040309@free.fr> Checking the attachment content will be somehow very difficult to implement, that's for sure. But as the user have to be logged in to attach files, and my opinion is that perhaps the good idea is to enforce the subscription process, either with randomly generated numbers in human-only generated images, to prevent automatic account creation. E-mail address checking process can be a good idea also. Maybe both ;) On 14/05/07 13:14, Teemu Mannermaa wrote: > On 14.05.2007 13:43, Gervase Markham wrote: >> I just had the below spam comment posted to my blog. It struck my eye >> because the URL is a Bugzilla attachment URL. > > Yeah, I have seen this problem reported before. Bmo was just hit with > such attachment a while ago (which justdave deleted promptly) and there > was a bug opened about this issue. See > https://bugzilla.mozilla.org/show_bug.cgi?id=380489 for details. > >> I'm not sure there's much we can do about this. The spammer obviously > > That was my thought exactly. I'm not sure what can be done about this > issue short of preventing HTML attachments or start parsing and > stripping bad code from them before showing. > > It does look like this problem is been exploited extensively. :( -- Motofix La route est longue, mais la voie est libre... http://www.jujunie.com From aaron.trevena at gmail.com Mon May 14 11:38:19 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Mon, 14 May 2007 12:38:19 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <464845F2.2040309@free.fr> References: <46483D24.5010802@mozilla.org> <46484487.3030803@etlicon.fi> <464845F2.2040309@free.fr> Message-ID: On 14/05/07, Julien BETI wrote: > Checking the attachment content will be somehow very difficult to > implement, that's for sure. Definately - that's an arms race you can't win, only mitigate the damage from. You can raise the bar a bit for comments that look like spam - I've seen that done in blogs and wikis, but again that's another arms race. > But as the user have to be logged in to > attach files, and my opinion is that perhaps the good idea is to > enforce the subscription process, either with randomly generated numbers > in human-only generated images, to prevent automatic account creation. > E-mail address checking process can be a good idea also. Maybe both ;) I've actually come accross several capchas that were broken - they are also a pain for the disabled unless you provide an alernative which is non-trivial. Email confirmation should be an easy win, but even that's not a watertight defence. The best solution may be social - medievel style outlawing of spammers.. ;) A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From chicks at chicks.net Mon May 14 11:51:01 2007 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 14 May 2007 07:51:01 -0400 Subject: Using Bugzilla to hide spam sites In-Reply-To: References: <46483D24.5010802@mozilla.org> <46484487.3030803@etlicon.fi> <464845F2.2040309@free.fr> Message-ID: <20070514115101.GG18411@chicks.net> On Mon, May 14, 2007 at 12:38:19PM +0100, Aaron Trevena wrote: > On 14/05/07, Julien BETI wrote: > >Checking the attachment content will be somehow very difficult to > >implement, that's for sure. > > Definately - that's an arms race you can't win, only mitigate the damage > from. Arms races are unwinnable, but sometimes its the only practical solution. Checking URL's in attachments against the various spam URL databases would seem harmless and take care of most of the problem for a little while. It won't win any races, but if it puts us ahead for a lap or two, so be it. MailScanner does this, its written in Perl, and it should be easy to make it optionally integratable in bugzilla. :) -- "The problem with troubleshooting is that trouble shoots back!" From aaron.trevena at gmail.com Mon May 14 12:03:31 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Mon, 14 May 2007 13:03:31 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <20070514115101.GG18411@chicks.net> References: <46483D24.5010802@mozilla.org> <46484487.3030803@etlicon.fi> <464845F2.2040309@free.fr> <20070514115101.GG18411@chicks.net> Message-ID: On 14/05/07, Christopher Hicks wrote: > On Mon, May 14, 2007 at 12:38:19PM +0100, Aaron Trevena wrote: > > On 14/05/07, Julien BETI wrote: > > >Checking the attachment content will be somehow very difficult to > > >implement, that's for sure. > > > > Definately - that's an arms race you can't win, only mitigate the damage > > from. > > Arms races are unwinnable, but sometimes its the only practical solution. Checking > URL's in attachments against the various spam URL databases would seem harmless > and take care of most of the problem for a little while. It won't win any races, but if it > puts us ahead for a lap or two, so be it. > > MailScanner does this, its written in Perl, and it should be easy to make it optionally > integratable in bugzilla. :) Also Spam Monkey - which checks for spam-like text or html using spamassasin rules. http://search.cpan.org/~simon/SpamMonkey-0.03/lib/SpamMonkey.pm but it's unsupported by it's author (because he's gone to japan to be a missionary, I kid you not) A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From chicks at chicks.net Mon May 14 12:10:09 2007 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 14 May 2007 08:10:09 -0400 Subject: Using Bugzilla to hide spam sites In-Reply-To: References: <46483D24.5010802@mozilla.org> <46484487.3030803@etlicon.fi> <464845F2.2040309@free.fr> <20070514115101.GG18411@chicks.net> Message-ID: <20070514121009.GK18411@chicks.net> On Mon, May 14, 2007 at 01:03:31PM +0100, Aaron Trevena wrote: > it's unsupported by it's author (because he's gone to japan to be a > missionary, I kid you not) New recommended Perl best practice: avoid modules in the missionary position! Sorry. I'll go grow up now. :) I kid you so! -- "The problem with troubleshooting is that trouble shoots back!" From aaron.trevena at gmail.com Mon May 14 12:14:43 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Mon, 14 May 2007 13:14:43 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <20070514121009.GK18411@chicks.net> References: <46483D24.5010802@mozilla.org> <46484487.3030803@etlicon.fi> <464845F2.2040309@free.fr> <20070514115101.GG18411@chicks.net> <20070514121009.GK18411@chicks.net> Message-ID: On 14/05/07, Christopher Hicks wrote: > On Mon, May 14, 2007 at 01:03:31PM +0100, Aaron Trevena wrote: > > it's unsupported by it's author (because he's gone to japan to be a > > missionary, I kid you not) > > New recommended Perl best practice: avoid modules in the missionary position! > > Sorry. I'll go grow up now. :) > > I kid you so! http://search.cpan.org/~jwalt/Acme-Lingua-NIGERIAN-1.0.0/NIGERIAN.pm Source filters considered harmful ;) A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From gerv at mozilla.org Mon May 14 12:36:27 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 14 May 2007 13:36:27 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <20070514115101.GG18411@chicks.net> References: <46483D24.5010802@mozilla.org> <46484487.3030803@etlicon.fi> <464845F2.2040309@free.fr> <20070514115101.GG18411@chicks.net> Message-ID: <464857CB.6030108@mozilla.org> Christopher Hicks wrote: > Arms races are unwinnable, but sometimes its the only practical > solution. Checking URL's in attachments against the various spam URL > databases would seem harmless and take care of most of the problem > for a little while. It won't win any races, but if it puts us ahead > for a lap or two, so be it. It wouldn't even put us ahead this lap. The attachment I linked to obfuscates the redirect URL using JavaScript. We could fix that, of course, if browsers supported serving content with a HTTP header which said "no script allowed"... http://www.gerv.net/security/content-restrictions/ Gerv From myk at mozilla.org Mon May 14 18:48:00 2007 From: myk at mozilla.org (Myk Melez) Date: Mon, 14 May 2007 11:48:00 -0700 Subject: Using Bugzilla to hide spam sites In-Reply-To: <46483D24.5010802@mozilla.org> References: <46483D24.5010802@mozilla.org> Message-ID: <4648AEE0.6070303@mozilla.org> Gervase Markham wrote: > I'm not sure there's much we can do about this. Could we make the ability to attach files require editbugs privileges? -myk From mkanat at bugzilla.org Mon May 14 19:33:31 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 14 May 2007 12:33:31 -0700 Subject: Using Bugzilla to hide spam sites In-Reply-To: <46483D24.5010802@mozilla.org> References: <46483D24.5010802@mozilla.org> Message-ID: <20070514193503.549811800B@help.trusthosting.net> On Mon, 14 May 2007 11:42:44 +0100 Gervase Markham wrote: > Short of implementing Captchas for account signup, or refusing to > display HTML attachments as HTML, I can't see a counter. I think we can make a captcha for account signup. That's not a problem. We can make it a parameter so admins can disable it if they want. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From gerv at mozilla.org Mon May 14 20:21:21 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 14 May 2007 21:21:21 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <4648AEE0.6070303@mozilla.org> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> Message-ID: <4648C4C1.5040704@mozilla.org> Myk Melez wrote: > Gervase Markham wrote: >> I'm not sure there's much we can do about this. > Could we make the ability to attach files require editbugs privileges? We could, perhaps if we also allowed it on bug submission. I have no data, but I'd suspect that a fair number of rookie bug reporters want to attach something like a screenshot. Alternatively, we could disallow text/html and other browser-displayable attachments (automatically switching them to text/plain) if the person didn't have canconfirm or editbugs (basically, any human-added permission). That might be the lowest impact. I really, really want to avoid captchas if we can help it. Gerv From mkanat at bugzilla.org Mon May 14 20:44:55 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 14 May 2007 13:44:55 -0700 Subject: Using Bugzilla to hide spam sites In-Reply-To: <4648C4C1.5040704@mozilla.org> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> Message-ID: <20070514204627.1992C18038@help.trusthosting.net> On Mon, 14 May 2007 21:21:21 +0100 Gervase Markham wrote: > We could, perhaps if we also allowed it on bug submission. I have no > data, but I'd suspect that a fair number of rookie bug reporters want > to attach something like a screenshot. I agree with Gerv here, actually. I think we really need to let non-editbugs reporters make attachments, for things like screenshots and HTML examples that reproduce bugs. > I really, really want to avoid captchas if we can help it. I think just having one during account creation would be OK. That makes it a lot harder to write bots that make automated accounts. (Of course, that's already pretty hard since they have to receive an email and then click the URL.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jochen.wiedmann at gmail.com Mon May 14 20:48:43 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Mon, 14 May 2007 22:48:43 +0200 Subject: Using Bugzilla to hide spam sites In-Reply-To: <20070514204627.1992C18038@help.trusthosting.net> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> Message-ID: On 5/14/07, Max Kanat-Alexander wrote: > I agree with Gerv here, actually. I think we really need to let > non-editbugs reporters make attachments, for things like screenshots > and HTML examples that reproduce bugs. After years of accepting bug reports for Apache projects where you need to be logged on to file the report, I'd say you're wrong. Whoever's seriously interested in the program will be happy to log in before attaching something. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From mkanat at bugzilla.org Mon May 14 20:57:23 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 14 May 2007 13:57:23 -0700 Subject: Using Bugzilla to hide spam sites In-Reply-To: References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> Message-ID: <20070514205855.6DD6E18038@help.trusthosting.net> On Mon, 14 May 2007 22:48:43 +0200 "Jochen Wiedmann" wrote: > After years of accepting bug reports for Apache projects where you > need to be logged on to file the report, I'd say you're wrong. > Whoever's seriously interested in the program will be happy to log in > before attaching something. Of course they will. All Bugzilla users have to log in to file a bug or attach something. We were talking about editbugs permissions, not about being logged in. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jochen.wiedmann at gmail.com Mon May 14 21:12:10 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Mon, 14 May 2007 23:12:10 +0200 Subject: Using Bugzilla to hide spam sites In-Reply-To: <20070514205855.6DD6E18038@help.trusthosting.net> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <20070514205855.6DD6E18038@help.trusthosting.net> Message-ID: On 5/14/07, Max Kanat-Alexander wrote: > We were talking about editbugs permissions, not about being > logged in. Sorry, my fault to get this wrong. Of course, I'm with you here. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From gerv at mozilla.org Mon May 14 21:20:43 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 14 May 2007 22:20:43 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <20070514204627.1992C18038@help.trusthosting.net> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> Message-ID: <4648D2AB.2070906@mozilla.org> Max Kanat-Alexander wrote: > I agree with Gerv here, actually. I think we really need to let > non-editbugs reporters make attachments, for things like screenshots > and HTML examples that reproduce bugs. Pondering more, I think the Content-Type restriction I suggested might well fix this in the lowest profile way possible. After all, anyone with editbugs (such as a triager) could switch the Content Type to the "right" one, and we'd accept that change. Gerv From mkanat at bugzilla.org Mon May 14 21:35:14 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 14 May 2007 14:35:14 -0700 Subject: Using Bugzilla to hide spam sites In-Reply-To: <4648D2AB.2070906@mozilla.org> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> Message-ID: <20070514213646.3FBE21800B@help.trusthosting.net> On Mon, 14 May 2007 22:20:43 +0100 Gervase Markham wrote: > Pondering more, I think the Content-Type restriction I suggested > might well fix this in the lowest profile way possible. After all, > anyone with editbugs (such as a triager) could switch the Content > Type to the "right" one, and we'd accept that change. Oh, I see. So they can still attach the thing, it just shows up as text/plain until they set it otherwise. Would we do that by setting a list of "dangerous" types? I think that might be a bit hard to make/maintain. But it could probably be done. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From djm at mindrot.org Mon May 14 22:39:26 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 May 2007 08:39:26 +1000 (EST) Subject: Using Bugzilla to hide spam sites In-Reply-To: <46483D24.5010802@mozilla.org> References: <46483D24.5010802@mozilla.org> Message-ID: On Mon, 14 May 2007, Gervase Markham wrote: > Developers, > > I just had the below spam comment posted to my blog. It struck my eye because > the URL is a Bugzilla attachment URL. > Viewing it in "edit" mode: > http://bugzilla.lyx.org/attachment.cgi?id=1638&action=edit > shows that the spammer has attached a copy of their pills sale page. It turns > out that it contains embedded obfuscated JS code which redirects you to the > real thing if you visit the attachment. So they are using Bugzilla to avoid > any domain blacklists in my blogging software. > > I'm not sure there's much we can do about this. The spammer obviously took > time to create an account - perhaps automatically, perhaps not. Short of > implementing Captchas for account signup, or refusing to display HTML > attachments as HTML, I can't see a counter. > > Thoughts? I got a bunch of these in the OpenSSH bugzilla, so I added a hack to simply ban all attachments that look like HTML from non-administrators. This works for us, because we don't really deal with HTML but obviously isn't a solution for everyone. -d From djm at mindrot.org Mon May 14 22:47:33 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 May 2007 08:47:33 +1000 (EST) Subject: Using Bugzilla to hide spam sites In-Reply-To: <20070514213646.3FBE21800B@help.trusthosting.net> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> <20070514213646.3FBE21800B@help.trusthosting.net> Message-ID: On Mon, 14 May 2007, Max Kanat-Alexander wrote: > On Mon, 14 May 2007 22:20:43 +0100 Gervase Markham > wrote: > > Pondering more, I think the Content-Type restriction I suggested > > might well fix this in the lowest profile way possible. After all, > > anyone with editbugs (such as a triager) could switch the Content > > Type to the "right" one, and we'd accept that change. > > Oh, I see. So they can still attach the thing, it just shows > up as text/plain until they set it otherwise. It isn't so simple: IE will "sniff" the content type and treat even document served as text/plain as HTML if it sees a HTML-like code in the first few hundred bytes. -d From gerv at mozilla.org Mon May 14 23:06:43 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 15 May 2007 00:06:43 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> <20070514213646.3FBE21800B@help.trusthosting.net> Message-ID: <4648EB83.5010100@mozilla.org> Damien Miller wrote: > It isn't so simple: IE will "sniff" the content type and treat even > document served as text/plain as HTML if it sees a HTML-like code in the > first few hundred bytes. Hey, they made their bed, they can lie in it. Is IE 7 better in this regard? Can we set the MIME type to application/octet-stream with content-disposition: Download for IE, then? Gerv From kristis.makris at asu.edu Mon May 14 23:03:44 2007 From: kristis.makris at asu.edu (Kristis Makris) Date: Mon, 14 May 2007 16:03:44 -0700 Subject: Using Bugzilla to hide spam sites In-Reply-To: References: <46483D24.5010802@mozilla.org> <46484487.3030803@etlicon.fi> <464845F2.2040309@free.fr> Message-ID: <1179183824.2629.14.camel@syd.mkgnu.net> On Mon, 2007-05-14 at 12:38 +0100, Aaron Trevena wrote: > The best solution may be social - medievel style outlawing of spammers.. ;) Or not allowing anyone to create a user account. It's similar to inviting the whole world to a party at your house, or just the people you know. People you know are more likely to care enough not to break things. From gerv at mozilla.org Tue May 15 11:17:08 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 15 May 2007 12:17:08 +0100 Subject: [Fwd: Feature focus - status/keywords/flags/fields] Message-ID: <464996B4.8050200@mozilla.org> What was the resolution on the idea to unify this list and mozilla.dev.apps.bugzilla? I note that my message (below) to that group got no responses, while I suspect it would and will get quite a few here. Gerv -------- Original Message -------- Subject: Feature focus - status/keywords/flags/fields Date: Fri, 11 May 2007 17:59:34 +0100 From: Gervase Markham Newsgroups: mozilla.dev.apps.bugzilla I recently wrote to someone: "I personally think the Bugzilla team needs to sort out the relationship between the status whiteboard, keywords, flags and custom fields, to make sure that we don't spend ages enhancing one just to find we've reinvented another of them. But we haven't had that discussion yet, because nothing has prompted it." Then I decided to prompt it. So here I am. Status whiteboard begat keywords, and keywords begat flags. Now people are suggesting that flags be enhanced to allow arbitrary values instead of just " ? + -". Wouldn't that make them like custom fields? Also, what account should Bugzilla take of the new tagging phenomenon? Is that like keywords or like the status whiteboard? Do we still need all four of these features, or can two be merged? Lots to discuss :-) Gerv From gerv at mozilla.org Tue May 15 11:49:52 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 15 May 2007 12:49:52 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <20070514213646.3FBE21800B@help.trusthosting.net> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> <20070514213646.3FBE21800B@help.trusthosting.net> Message-ID: <46499E60.5010001@mozilla.org> Max Kanat-Alexander wrote: > Oh, I see. So they can still attach the thing, it just shows > up as text/plain until they set it otherwise. > > Would we do that by setting a list of "dangerous" types? I > think that might be a bit hard to make/maintain. But it could probably > be done. It wouldn't be all that hard to maintain. The list of browser-displayable, scriptable types doesn't change all that often. Of course, instead of a blacklist, we could have a whitelist. Perhaps text/plain, application/zip, application/octet-stream and a few others. Alternatively, we could invent our own MIME types, application/x-bugzilla-upload-text and application/x-bugzilla-upload-binary, which was set on all uploads from non-permissioned people by default. When actually serving it, we'd detect IE and serve Content-Disposition: attachment, and detect Firefox and use text/plain or application/octet-stream. Would something like this fly? Or should we just accept this as a fact of life? Gerv From gerv at mozilla.org Tue May 15 13:17:56 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 15 May 2007 14:17:56 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4645E1F9.2040503@mozilla.org> References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <4645C0A4.9020806@bugzilla.org> <4645E1F9.2040503@mozilla.org> Message-ID: <4649B304.4090706@mozilla.org> Myk Melez wrote: > For me those times approach 100%, and I suspect most Bugzilla users (and > many users of other applications that page information, often to > increase ad views) feel the same, in which case paging bug lists by > default would be a big step backwards. I agree; the great thing about a single-page list is that you can do quick-and-dirty subsearch using Find In Page. This is a feature I think people would miss. And given that it works now, and b.m.o. manages to stay up, I don't see a need to eliminate it. We might, of course, want to page results coming from the database, reading each page and then "forgetting" it as we write out the template, to reduce server-side memory usage while still having everything on one big HTML page. Gerv From gerv at mozilla.org Tue May 15 13:38:40 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 15 May 2007 14:38:40 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <20070503003115.DFF301817A@help.trusthosting.net> <4644BE9F.60409@mozilla.org> <20070512194140.F1AF4118031@help.trusthosting.net> Message-ID: <4649B7E0.8010904@mozilla.org> Jochen Wiedmann wrote: > And, in fact, I wonder why you are considering a rewrite: Why not > simply pushing Scarab? IMO, it was created out of rather similar > considerations? IMO (tangentially relevant), Scarab is a poster child for why "let's rewrite this product to use these cool new technologies which will make everything better and faster and quicker and sexier and, and, and..." is a bad idea. (Yes, I exaggerate for effect.) At the time, the cool new thing was Java Servlets. Their original feature list[0] basically boiled down to "like Bugzilla, but in Java". It went into "beta" in early 2002. That's 5 years ago. If there's any product which has got lost in what the Loginataka[1] refers to as "the ghastly limbo called Perpetual Beta", it's Scarab. In February of this year, they seem to have removed the "beta" designation, and gone from 1.0-beta20 to "0.21". And the front page calls it "stable". Admittedly, my judgment may be coloured by one of its lead developers walking into our newsgroup a few years ago and demanding in rather rude terms that we buck our ideas up and fix Bugzilla to make it easier for him to migrate lots of people to his tool. But I try not to let it be so. Gerv [0] http://web.archive.org/web/20020225155214/http://scarab.tigris.org/index.html [1] http://catb.org/~esr/faqs/loginataka.html From gerv at mozilla.org Tue May 15 13:44:19 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 15 May 2007 14:44:19 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <52828.1179076991@thrush.ravenbrook.com> Message-ID: <4649B933.4060403@mozilla.org> Thank you for your apology. Aaron Trevena wrote: > I've just tried to point out (sometimes in an ill-tempered or harsh > manner, I'm afraid), that the problem is social rather than technical > in nature, and the solution is to learn to write code better, rather > than write the same bad code in a new language. I think it would be really, really cool if some of the gurus in the Perl world were to spend some time looking at Bugzilla and making constructive suggestions, in bang-for-buck order, about what we might change about our code or our processes to make live easier for developers or users. Yes, it would take some time - at least a few hours for each person - but it would be a wonderful service that the Perl community could perform to benefit (indirectly) the free software community as a whole. Aaron, if you have the contacts and could arrange something like this, perhaps on a Saturday afternoon one weekend with all the people in an IRC channel (so the Bugzilla developers can answer the Perl gurus' questions)... Gerv From aaron.trevena at gmail.com Tue May 15 16:27:11 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Tue, 15 May 2007 17:27:11 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4649B933.4060403@mozilla.org> References: <52828.1179076991@thrush.ravenbrook.com> <4649B933.4060403@mozilla.org> Message-ID: On 15/05/07, Gervase Markham wrote: > Thank you for your apology. In the words of Sir Lancelot : "Sorry. Sorry! You see what I mean, I just get carried away, I'm really most awfully sorry. Sorry! Sorry, everyone...." :) > I think it would be really, really cool if some of the gurus in the Perl > world were to spend some time looking at Bugzilla and making > constructive suggestions, in bang-for-buck order, about what we might > change about our code or our processes to make live easier for > developers or users. Yes, it would take some time - at least a few hours > for each person - but it would be a wonderful service that the Perl > community could perform to benefit (indirectly) the free software > community as a whole. and moving on.. "Please! This is supposed to be a...*happy* occasion! Let's not *bicker* and *argue* about 'oo killed 'oo!" [1] > Aaron, if you have the contacts and could arrange something like this, > perhaps on a Saturday afternoon one weekend with all the people in an > IRC channel (so the Bugzilla developers can answer the Perl gurus' > questions)... I think I have the contacts although I think a couple of the bugzilla people have burnt some bridges with some of the trolling on the wiki.. Randal was only half joking when he said ""We'd actually prefer you stop using Perl. You seem to be giving it a bad name. KTHX, Bye". Fortunately there are few people who seem to be interested in sorting out bugzilla, for the same reason as a cabal created the NMS replacement for MSA, MSA was giving perl a bad name and teaching newbies very bad practice, on top of being utterly insecure. Bugzilla is nowhere near that bad - and the inclusion of TT, Email::* and (as I only noticed the other day) a bunch of actual Test::Harness tests in t/, is a pretty good sign of things moving forwards. I'll ask around, and I still say that (optional) pagination could be very useful - I used find-in-page for a long list in one of my own applications today and it's really rather better to paginate results and provide a way of further restricting those results. Something that Bugzilla could do for the perl community is to work together to find the best solution for packaging CPAN modules into a standalone application - the catalyst people have been working hard on making CPAN dependancies less of an obstacle for installation, and PAR could certainly be a solution for Bugzilla. Cheers, Aaron 1] http://www.intriguing.com/mp/_pictures/grail/large/HolyGrail136.jpg -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From aaron.trevena at gmail.com Tue May 15 16:34:50 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Tue, 15 May 2007 17:34:50 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <46499E60.5010001@mozilla.org> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> <20070514213646.3FBE21800B@help.trusthosting.net> <46499E60.5010001@mozilla.org> Message-ID: On 15/05/07, Gervase Markham wrote: > Max Kanat-Alexander wrote: > > Oh, I see. So they can still attach the thing, it just shows > > up as text/plain until they set it otherwise. > > > > Would we do that by setting a list of "dangerous" types? I > > think that might be a bit hard to make/maintain. But it could probably > > be done. > > It wouldn't be all that hard to maintain. The list of > browser-displayable, scriptable types doesn't change all that often. > > Of course, instead of a blacklist, we could have a whitelist. Perhaps > text/plain, application/zip, application/octet-stream and a few others. White-list would be better - pretty much every filetype except plain text has been exploited in windows to date, from .ico to .scr to images and pretty much any kind of file that windows uses for anything. > Alternatively, we could invent our own MIME types, > application/x-bugzilla-upload-text and > application/x-bugzilla-upload-binary, which was set on all uploads from > non-permissioned people by default. When actually serving it, we'd > detect IE and serve Content-Disposition: attachment, and detect Firefox > and use text/plain or application/octet-stream. > > Would something like this fly? You might already be able to do that as a > Or should we just accept this as a fact of life? >From what I've seen on list - one of the bugzilla developers redeeming qualities have been their attention to security. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From aaron.trevena at gmail.com Tue May 15 16:35:56 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Tue, 15 May 2007 17:35:56 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> <20070514213646.3FBE21800B@help.trusthosting.net> <46499E60.5010001@mozilla.org> Message-ID: On 15/05/07, Aaron Trevena wrote: > > Alternatively, we could invent our own MIME types, > > application/x-bugzilla-upload-text and > > application/x-bugzilla-upload-binary, which was set on all uploads from > > non-permissioned people by default. When actually serving it, we'd > > detect IE and serve Content-Disposition: attachment, and detect Firefox > > and use text/plain or application/octet-stream. > > > > Would something like this fly? > You might already be able to do that as a .. You might already be able to do that as an apache configuration. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From bugzilla at glob.com.au Tue May 15 17:03:38 2007 From: bugzilla at glob.com.au (byron) Date: Wed, 16 May 2007 01:03:38 +0800 Subject: Using Bugzilla to hide spam sites In-Reply-To: References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> <20070514213646.3FBE21800B@help.trusthosting.net> <46499E60.5010001@mozilla.org> Message-ID: <20070515170338.GA22546@bur.st> > You might already be able to do that as an apache configuration. we can't rely on apache configuration for a number of reasons. admins may not have access to modify the apache config, and they tend to not work on iis. -b begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== From gerv at mozilla.org Tue May 15 17:15:50 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 15 May 2007 18:15:50 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <52828.1179076991@thrush.ravenbrook.com> <4649B933.4060403@mozilla.org> Message-ID: <4649EAC6.8000308@mozilla.org> Aaron Trevena wrote: > I think I have the contacts although I think a couple of the bugzilla > people have burnt some bridges with some of the trolling on the wiki.. > Randal was only half joking when he said ""We'd actually prefer you > stop using Perl. You seem to be giving it a bad name. KTHX, Bye". I missed all this wiki stuff... I had no idea that we'd had some sort of flame war. Maybe everyone needs to just take a week off, cool down, we can pretend this all never happened, and start again with a clean slate? > Something that Bugzilla could do for the perl community is to work > together to find the best solution for packaging CPAN modules into a > standalone application - the catalyst people have been working hard on > making CPAN dependancies less of an obstacle for installation, and PAR > could certainly be a solution for Bugzilla. Are they an obstacle even on Unix? I've never had much problem with them recently, but then maybe I've done it quite a few times. Wasn't Bundle:: invented to solve this? Gerv From aaron.trevena at gmail.com Tue May 15 17:48:50 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Tue, 15 May 2007 18:48:50 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4649EAC6.8000308@mozilla.org> References: <52828.1179076991@thrush.ravenbrook.com> <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> Message-ID: On 15/05/07, Gervase Markham wrote: > Aaron Trevena wrote: > > I think I have the contacts although I think a couple of the bugzilla > > people have burnt some bridges with some of the trolling on the wiki.. > > Randal was only half joking when he said ""We'd actually prefer you > > stop using Perl. You seem to be giving it a bad name. KTHX, Bye". > > I missed all this wiki stuff... I had no idea that we'd had some sort of > flame war. > > Maybe everyone needs to just take a week off, cool down, we can pretend > this all never happened, and start again with a clean slate? I've cooled down now. I first donned my asbestos typing gloves on bbs and mailing lists a dozen or so years ago.. heck I even managed to work with somebody who responded with his fists to something I said when I was treasurer or our uni computing society.. perhaps our sailing trip had an alterior motive beyond pretending to be members of sailing soc in order to blag a dinghy for the afternoon and getting towed back from the rip by Drake Island saved me from davey jones locker.. > > Something that Bugzilla could do for the perl community is to work > > together to find the best solution for packaging CPAN modules into a > > standalone application - the catalyst people have been working hard on > > making CPAN dependancies less of an obstacle for installation, and PAR > > could certainly be a solution for Bugzilla. > > Are they an obstacle even on Unix? > > I've never had much problem with them recently, but then maybe I've done it quite a > few times. Wasn't Bundle:: invented to solve this? Apparently so. Debian/redhat perl packages can be out of date (sometimes by years) or just plain broken or configured by crack monkeys, or can clash with cpan modules so you have multiple versions, etc (I don't think this is unique to perl packaging - distro package quality varies wildly accross all software on all distributions). Large numbers of dependancies can be problematic - a test could fail for some reason high up in the dependancy chain breaking automatic installation for everything relying on it, some crypto modules won't install without you specifying which particular obscure implementation of an encryption algorithm you haven't heard of, etc. Of course some users don't have the knowhow to use CPAN - there is no technical reason not to use it anywhere with an internet connection, only lack of awareness of it, or how to use it as a non-root user, or issues with policies on installing software. That doesn't mean you shouldn't use CPAN modules - it just means you need to make it your problem rather than the users to install the right software - you can bundle dependancies along with the package and only install them if they aren't already installed or are newer than those installed - makefiles can handle this fairly well, you can also use PAR, and or create a custom linux package that provides the required stuff. Making Perl applications installable easily for people who don't know unix or perl well is something a chunk of perl community is interested in, as it would increase deployment of frameworks like Catalyst and applications built on them. It could also make life easier for those of us that develop bespoke systems to deploy and change control our software. .. for example currently I'm building debian packages of about 30,000 LoC (according to sllocount, and excluding dependancies) and will be deploying that to staging, test and production servers in stages over the next few weeks and months. I'm prototyping an automated system using cpanplus::dist and dpkg::parser at the moment. Cheers, A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From aaron.trevena at gmail.com Tue May 15 17:49:50 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Tue, 15 May 2007 18:49:50 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <20070515170338.GA22546@bur.st> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> <20070514213646.3FBE21800B@help.trusthosting.net> <46499E60.5010001@mozilla.org> <20070515170338.GA22546@bur.st> Message-ID: On 15/05/07, byron wrote: > > You might already be able to do that as an apache configuration. > > we can't rely on apache configuration for a number of reasons. admins > may not have access to modify the apache config, and they tend to not > work on iis. Indeed. I was suggesting a workaround :) A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From jake at bugzilla.org Tue May 15 19:12:05 2007 From: jake at bugzilla.org (Jake) Date: Tue, 15 May 2007 15:12:05 -0400 Subject: [Fwd: Feature focus - status/keywords/flags/fields] In-Reply-To: <464996B4.8050200@mozilla.org> References: <464996B4.8050200@mozilla.org> Message-ID: A voice from afar said.... On 5/15/07, Gervase Markham wrote: > > Status whiteboard begat keywords, and keywords begat flags. Now people > are suggesting that flags be enhanced to allow arbitrary values instead > of just " ? + -". Wouldn't that make them like custom fields? I do believe it would basically make them an enumerated form of a custom field with the ability to attach events to them (email when they're sent, iirc) Also, > what account should Bugzilla take of the new tagging phenomenon? Is that > like keywords or like the status whiteboard? I've seen many people using the status whiteboard as a poor-man's tagging before. Perhaps it wouldn't be a horrible idea to do tags in a manner that they are personal/private. Then if I wanted to tag something I wouldn't have to use the status whiteboard and do something silly like [jake:p1]. Global tags are really kinda what keywords are. If there was an inclination to make tags global, I'd suggest instead expanding keywords and adding a public/private option. While there is overlap, I think that keywords/flags/status whiteboard all serve distinct purposes: Flags can trigger events and be requested, added, or denied and have permissions set appropriately. Keywords are globally defined and can be tracked and managed across an entire project. Status whiteboard is an unstructured field that resides near the top of the form, is searchable, and can contain darn near anything. Custom fields is where the lines start to blur. I remember early on in the custom field discussion the topic of turning the whiteboard into a custom field came up. Did that not end up happening? Some of the same weaknesses of the whiteboard that caused keywords (not centrally managed) to be created are strengths that caused it to stick around. Same goes for keywords/flags. Do we still need all four > of these features, or can two be merged? > It may be possible to merge a couple, but I think it'd be better to make the whiteboard a custom field and rework keywords into tags. Though I'm not volunteering to code it being that I'm so far out of the loop :). -- http://jacob.steenhagen.us -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Tue May 15 19:31:38 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 15 May 2007 21:31:38 +0200 Subject: [Fwd: Feature focus - status/keywords/flags/fields] In-Reply-To: References: <464996B4.8050200@mozilla.org> Message-ID: <464A0A9A.1080204@gmail.com> You can already tags bugs individually and personaly. Look at the "Enable tags for bugs" user pref. LpSolit From myk at mozilla.org Tue May 15 19:31:56 2007 From: myk at mozilla.org (Myk Melez) Date: Tue, 15 May 2007 12:31:56 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <4649EAC6.8000308@mozilla.org> References: <52828.1179076991@thrush.ravenbrook.com> <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> Message-ID: <464A0AAC.7080606@mozilla.org> Gervase Markham wrote: > I missed all this wiki stuff... I had no idea that we'd had some sort > of flame war. We didn't. Aaron is misrepresenting what happened on the Bugzilla:Languages discussion page . What actually happened is that folks had a mostly reasonable discussion with the notable exception of Aaron himself, who both falsely accused Max of trolling on the Bugzilla:Languages page and engaged in trolling of his own. > Maybe everyone needs to just take a week off, cool down, we can > pretend this all never happened, and start again with a clean slate? As far as I can tell, no one has lost their cool except Aaron, so I don't think it makes sense for everyone to take time off to cool down. Rather, Aaron should stop trolling or leave the discussion. And in recent messages it appears that he has stopped trolling, so the problem has been resolved. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From myk at mozilla.org Tue May 15 19:46:23 2007 From: myk at mozilla.org (Myk Melez) Date: Tue, 15 May 2007 12:46:23 -0700 Subject: [Fwd: Feature focus - status/keywords/flags/fields] In-Reply-To: <464996B4.8050200@mozilla.org> References: <464996B4.8050200@mozilla.org> Message-ID: <464A0E0F.4050006@mozilla.org> Gervase Markham wrote: > What was the resolution on the idea to unify this list and > mozilla.dev.apps.bugzilla? I note that my message (below) to that > group got no responses, while I suspect it would and will get quite a > few here. There was none. I wrote a message on 2006/04/24 asking about the status of hooking up the list to the newsgroup, which we'd previously decided we should do. Dave responded with two options for doing it (forwarding or gatewaying), of which he seemed to prefer forwarding because it's easier to do. Max then agreed with Dave that we should do forwarding, despite not wanting to switch from developers at bugzilla.org to dev-apps-bugzilla at lists.mozilla.org (although it's not clear that forwarding actually requires this). And Fr?d?ric then seconded Max's preference for developers at mozilla.org. And that's where we left it. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.trevena at gmail.com Tue May 15 20:00:15 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Tue, 15 May 2007 21:00:15 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <464A0AAC.7080606@mozilla.org> References: <52828.1179076991@thrush.ravenbrook.com> <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> <464A0AAC.7080606@mozilla.org> Message-ID: On 15/05/07, Myk Melez wrote: > >> Gervase Markham wrote: >> I missed all this wiki stuff... I had no idea that we'd had some sort of flame war. > We didn't. Aaron is misrepresenting what happened on the > Bugzilla:Languages discussion page. What actually happened is that folks > had a mostly reasonable discussion with the notable exception of Aaron > himself, who both falsely accused Max of trolling on the Bugzilla:Languages > page and engaged in trolling of his own. I didn't troll - I added 2 entries to python cons, and toned down some of the hyperbole - in fact my modifications to python cons are pretty much unchanged, because they weren't trolling. I don't believe Max is to blame for all of the FUD about perl on the wiki, but he has hampered the correcting of it. None of the feedback and corrections about his (and others) Perl cons in the discussions page have made it to the main page which Max has locked to prevent anybody correcting it. > Maybe everyone needs to just take a week off, cool down, we can pretend this > all never happened, and start again with a clean slate? > As far as I can tell, no one has lost their cool except Aaron, so I don't > think it makes sense for everyone to take time off to cool down. Rather, > Aaron should stop trolling or leave the discussion. And in recent messages > it appears that he has stopped trolling, so the problem has been resolved. I would call some of Max's actions losing his cool, and many of the FUD comments about Perl in the wiki have been pretty outrageous. But I've chilled, and apologised, even if Max refuses to talk to me or allow me to correct the wiki page. regards, A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From myk at mozilla.org Tue May 15 20:15:10 2007 From: myk at mozilla.org (Myk Melez) Date: Tue, 15 May 2007 13:15:10 -0700 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: References: <52828.1179076991@thrush.ravenbrook.com> <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> <464A0AAC.7080606@mozilla.org> Message-ID: <464A14CE.3030105@mozilla.org> Aaron Trevena wrote: > I didn't troll - I added 2 entries to python cons, and toned down some > of the hyperbole - in fact my modifications to python cons are pretty > much unchanged, because they weren't trolling. This constitutes trolling in my book: "Apparently Max's contributions are sancrosanct because even if they are debunked, incorrect, entirely subjective or just plain trolling they can't be removed from the wiki page itself on penalty of locking the page and throwing toys out of the pram." And this comes close: "yes. learn about context. it's not rocket science - anybody finding this hard would have a terrible time with a strictly typed language." -myk From aaron.trevena at gmail.com Tue May 15 20:26:13 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Tue, 15 May 2007 21:26:13 +0100 Subject: The Problems of Perl: The Future of Bugzilla In-Reply-To: <464A14CE.3030105@mozilla.org> References: <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> <464A0AAC.7080606@mozilla.org> <464A14CE.3030105@mozilla.org> Message-ID: On 15/05/07, Myk Melez wrote: > Aaron Trevena wrote: > > I didn't troll - I added 2 entries to python cons, and toned down some > > of the hyperbole - in fact my modifications to python cons are pretty > > much unchanged, because they weren't trolling. > This constitutes trolling in my book: > > "Apparently Max's contributions are sancrosanct because even if they are > debunked, incorrect, entirely subjective or just plain trolling they > can't be removed from the wiki page itself on penalty of locking the > page and throwing toys out of the pram." > > And this comes close: > > "yes. learn about context. it's not rocket science - anybody finding > this hard would have a terrible time with a strictly typed language." Undiplomatic, yes. But I wouldn't call it trolling - I suppose that's subjective - like 90% of the language discussion page (for and against every language) ;) A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From jake at bugzilla.org Wed May 16 12:07:57 2007 From: jake at bugzilla.org (Jake) Date: Wed, 16 May 2007 08:07:57 -0400 Subject: [Fwd: Feature focus - status/keywords/flags/fields] In-Reply-To: <464A0A9A.1080204@gmail.com> References: <464996B4.8050200@mozilla.org> <464A0A9A.1080204@gmail.com> Message-ID: On 5/15/07, Fr?d?ric Buclin wrote: > > You can already tags bugs individually and personaly. Look at the > "Enable tags for bugs" user pref. > > Like I said, I've been out of the loop... So much so that the loop may have forgotten that I exist :). -- http://jacob.steenhagen.us -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwilliss at microimages.com Wed May 16 14:16:19 2007 From: dwilliss at microimages.com (Dave Williss) Date: Wed, 16 May 2007 09:16:19 -0500 Subject: Alternate way to store attachments? Message-ID: <464B1233.5020504@microimages.com> Would it be possible to implement an alternate method of storing attachments? Rather than storing them in blobs in the database, we'd like to store them on a normal filesystem. We do this currently anyway but in a way that Bugzilla doesn't know anything about the files. We have an "errdata" directory on our main fileserver with subdirectories which are bug numbers. Support puts data into those directories. These aren't tiny patches or anything like that either. Sometimes they're hundreds of megabytes. What I'd like is a way to upload the attachments to this directory through bugzilla and also have bugzilla keep a record of who uploaded what and the description. As another useful utility, we have a script (a DOS batch file, actually) called geterrdata which takes a bug number and copies the contents of the errdata directory for that bug to a local errdata folder. This makes it easier for the developer to get at the data and reproduce and fix the error. Yet another script runs via cron nightly and deletes the errdata folder for any bug which has been closed for more than 2 weeks. --Dave Williss From lpsolit at gmail.com Wed May 16 14:25:16 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 16 May 2007 16:25:16 +0200 Subject: Alternate way to store attachments? In-Reply-To: <464B1233.5020504@microimages.com> References: <464B1233.5020504@microimages.com> Message-ID: <464B144C.6000009@gmail.com> Dave Williss a ?crit : > Rather than storing them in blobs in the database, we'd like to store > them on a normal filesystem. You can already do that. Go to editparams.cgi?section=attachment#maxlocalattachment and set it to a low value. When you attach a file, a checkbox is displayed allowing you to store it in data/attachments/. You can then use these attachments as any other attachments stored in the DB. Bugzilla does all the work for you. LpSolit From justdave at bugzilla.org Wed May 16 14:26:51 2007 From: justdave at bugzilla.org (David Miller) Date: Wed, 16 May 2007 10:26:51 -0400 Subject: Alternate way to store attachments? In-Reply-To: <464B1233.5020504@microimages.com> References: <464B1233.5020504@microimages.com> Message-ID: <464B14AB.1090203@bugzilla.org> Dave Williss wrote on 5/16/07 10:16 AM: > Would it be possible to implement an alternate method of storing > attachments? > Rather than storing them in blobs in the database, we'd like to store > them on a normal filesystem. Bugzilla already does this, in 2.20 and up. Look for the maxlocalattachment parameter. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From wicked at etlicon.fi Wed May 16 15:26:33 2007 From: wicked at etlicon.fi (Teemu Mannermaa) Date: Wed, 16 May 2007 18:26:33 +0300 Subject: Module dependencies and packages In-Reply-To: References: <52828.1179076991@thrush.ravenbrook.com> <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> Message-ID: <464B22A9.1060607@etlicon.fi> On 15.05.2007 20:49, Aaron Trevena wrote: > Debian/redhat perl packages can be out of date (sometimes by years) or Exactly, they are meant to be stable and not bleeding edge that might break things. Only security issues will get backports or module updates. This mostly applies to core packages but RPMforge ones tend to get updated more often. > just plain broken or configured by crack monkeys, or can clash with > cpan modules so you have multiple versions, etc (I don't think this is Yes, that's why it's never a good idea to use CPAN on systems with package management. Probably one of the important rules about package management is that you never ever should install anything without telling it to your package manager. Having unknown, unlisted files is a sure way to get you into trouble with package manager. > Large numbers of dependancies can be problematic - a test could fail > for some reason high up in the dependancy chain breaking automatic Yeah, I have seen problems from long dependency lists. Bugzilla just checks for the highest, direct requirement and not any extra modules required down on dependency chain. For example, I just noticed our inbound email interface requires Email::Date but it's not checked for and thus people are having problems. :( Package management can actually help here by making sure all requirements are pulled in whenever higher module is installed. That's how CPAN works too. > right software - you can bundle dependancies along with the package > and only install them if they aren't already installed or are newer For our Tinderbox installation that runs our automated test suite (the files under t/ subdirect) I ended up building special RPM files that contain different versions of supported Perl interpreters and required Perl modules. It wasn't that bad but making all those modules to build and especially making their tests pass was getting hard. :( -- Teemu Mannermaa System Specialist "Anything is possible. It's all about probabilities." From aaron.trevena at gmail.com Wed May 16 15:39:21 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Wed, 16 May 2007 16:39:21 +0100 Subject: Module dependencies and packages In-Reply-To: <464B22A9.1060607@etlicon.fi> References: <52828.1179076991@thrush.ravenbrook.com> <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> <464B22A9.1060607@etlicon.fi> Message-ID: On 16/05/07, Teemu Mannermaa wrote: > > just plain broken or configured by crack monkeys, or can clash with > > cpan modules so you have multiple versions, etc (I don't think this is > > Yes, that's why it's never a good idea to use CPAN on systems with > package management. Probably one of the important rules about package > management is that you never ever should install anything without > telling it to your package manager. Having unknown, unlisted files is a > sure way to get you into trouble with package manager. I'd go the other way around personally - anything that is critical to development means not relying on some distro maintainers to keep up to date - for serious systems it's better to use your own perl and CPAN. cpan and cpanplus are both package managers, they just do Perl rather than everything :) Also freebsd package management plays nice with CPAN - it's debian and redhat that are breaking things. > > right software - you can bundle dependancies along with the package > > and only install them if they aren't already installed or are newer > > For our Tinderbox installation that runs our automated test suite (the > files under t/ subdirect) I ended up building special RPM files that > contain different versions of supported Perl interpreters and required > Perl modules. It wasn't that bad but making all those modules to build > and especially making their tests pass was getting hard. :( Of course you can just use PAR. In fact using PAR and bundling it in with Bugzilla would make deployment a lot easier and simpler for new users. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From gerv at mozilla.org Wed May 16 16:43:46 2007 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 16 May 2007 17:43:46 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> <20070514213646.3FBE21800B@help.trusthosting.net> <46499E60.5010001@mozilla.org> Message-ID: <464B34C2.10201@mozilla.org> Aaron Trevena wrote: > White-list would be better - pretty much every filetype except plain > text has been exploited in windows to date, from .ico to .scr to > images and pretty much any kind of file that windows uses for > anything. True. But we are not here to try and make Windows boxes more secure. Let's get the low-hanging fruit. According to: http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/moniker/overview/appendix_a.asp "Note: In Internet Explorer 6 for Microsoft Windows XP Service Pack 2 (SP2), the MIME type "text/plain" is not ambiguous, and is never rendered as HTML in the restricted zone, even if the content suggests that this is the correct format." So, given that all IE users should be using the latest version and it's their own fault if they aren't, I suggest the following algorithm. We convert the following MIME types to text/plain if the attachment is attached by someone with no privileges whatsoever: text/html text/xml application/xml application/*+xml multipart/* And we note the original MIME type in the upload comment. That should stop the redirect in a great enough percentage of browsers so as to make spamming using Bugzilla attachment URLs uneconomical. Gerv From justdave at bugzilla.org Wed May 16 19:00:45 2007 From: justdave at bugzilla.org (David Miller) Date: Wed, 16 May 2007 15:00:45 -0400 Subject: Module dependencies and packages In-Reply-To: References: <52828.1179076991@thrush.ravenbrook.com> <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> <464B22A9.1060607@etlicon.fi> Message-ID: <464B54DD.5090208@bugzilla.org> Aaron Trevena wrote on 5/16/07 11:39 AM: > On 16/05/07, Teemu Mannermaa wrote: >> > just plain broken or configured by crack monkeys, or can clash with >> > cpan modules so you have multiple versions, etc (I don't think this is >> >> Yes, that's why it's never a good idea to use CPAN on systems with >> package management. Probably one of the important rules about package >> management is that you never ever should install anything without >> telling it to your package manager. Having unknown, unlisted files is a >> sure way to get you into trouble with package manager. > > I'd go the other way around personally - anything that is critical to > development means not relying on some distro maintainers to keep up to > date - for serious systems it's better to use your own perl and CPAN. Or roll your own RPMs. I tend to do that a lot. Most of the time building an RPM is pretty easy. And when you're running a couple hundred servers, it's a lifesaver to have a list of what the installed packages were to restore to a new machine with the data backups if a hard drive takes a nose-dive. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From dwilliss at microimages.com Wed May 16 19:43:52 2007 From: dwilliss at microimages.com (Dave Williss) Date: Wed, 16 May 2007 14:43:52 -0500 Subject: Alternate way to store attachments? In-Reply-To: <464B144C.6000009@gmail.com> References: <464B1233.5020504@microimages.com> <464B144C.6000009@gmail.com> Message-ID: <464B5EF8.8090908@microimages.com> But is there a way to configure where these attachments go? I suppose making data/attachments be a symbolic link to where I want them would work. Note: we're running Bugzilla 2.22. Fr?d?ric Buclin wrote: > Dave Williss a ?crit : >> Rather than storing them in blobs in the database, we'd like to store >> them on a normal filesystem. > > > You can already do that. Go to > editparams.cgi?section=attachment#maxlocalattachment and set it to a > low value. When you attach a file, a checkbox is displayed allowing > you to store it in data/attachments/. You can then use these > attachments as any other attachments stored in the DB. Bugzilla does > all the work for you. > > LpSolit > - > To view or change your list settings, click here: > > > From aaron.trevena at gmail.com Wed May 16 19:59:25 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Wed, 16 May 2007 20:59:25 +0100 Subject: Module dependencies and packages In-Reply-To: <464B54DD.5090208@bugzilla.org> References: <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> <464B22A9.1060607@etlicon.fi> <464B54DD.5090208@bugzilla.org> Message-ID: On 16/05/07, David Miller wrote: > Aaron Trevena wrote on 5/16/07 11:39 AM: > > On 16/05/07, Teemu Mannermaa wrote: > >> > just plain broken or configured by crack monkeys, or can clash with > >> > cpan modules so you have multiple versions, etc (I don't think this is > >> > >> Yes, that's why it's never a good idea to use CPAN on systems with > >> package management. Probably one of the important rules about package > >> management is that you never ever should install anything without > >> telling it to your package manager. Having unknown, unlisted files is a > >> sure way to get you into trouble with package manager. > > > > I'd go the other way around personally - anything that is critical to > > development means not relying on some distro maintainers to keep up to > > date - for serious systems it's better to use your own perl and CPAN. > > Or roll your own RPMs. I tend to do that a lot. Most of the time > building an RPM is pretty easy. And when you're running a couple > hundred servers, it's a lifesaver to have a list of what the installed > packages were to restore to a new machine with the data backups if a > hard drive takes a nose-dive. Yeah. As it happens I'm rolling our stuff up into debian packages. cpanplus::dist::deb to the rescue using dpkg::parse to build an ignore list A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From byron at glob.com.au Thu May 17 00:44:18 2007 From: byron at glob.com.au (byron) Date: Thu, 17 May 2007 08:44:18 +0800 Subject: Using Bugzilla to hide spam sites In-Reply-To: <464B34C2.10201@mozilla.org> References: <46483D24.5010802@mozilla.org> <4648AEE0.6070303@mozilla.org> <4648C4C1.5040704@mozilla.org> <20070514204627.1992C18038@help.trusthosting.net> <4648D2AB.2070906@mozilla.org> <20070514213646.3FBE21800B@help.trusthosting.net> <46499E60.5010001@mozilla.org> <464B34C2.10201@mozilla.org> Message-ID: <20070517004418.GA10971@bur.st> > http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/moniker/overview/appendix_a.asp > "Note: In Internet Explorer 6 for Microsoft Windows XP Service Pack 2 > (SP2), the MIME type "text/plain" is not ambiguous, and is never > rendered as HTML in the restricted zone, even if the content suggests > that this is the correct format." > > So, given that all IE users should be using the latest version and it's > their own fault if they aren't, I suggest the following algorithm. the key part of that quote is "in the restricted zone". internet sites are not in this zone by default. as part of the xsp2 beta microsoft experimented with disabling mime type sniffing, however they ended up reenabling it due to the number of broken sites. it's now a security setting: Miscellaneous --> Open files based on content, not file extension this option is enabled by default on the internet zone, so we can't rely on it being enabled. begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== From jeff.lasslett at datataker.com.au Thu May 17 04:24:36 2007 From: jeff.lasslett at datataker.com.au (Jeff Lasslett) Date: Thu, 17 May 2007 14:24:36 +1000 Subject: Adding an XML-RPC to append comments Message-ID: <1179375876.13828.28.camel@jeff> Hello, I've added the following subroutine to Bugzilla/WebServices/Bug.pm. The goal is to be able to add comments to bugs using XML-RPC. The routine is called as a web service. The arguments seem to be correct. The trouble is that no comments are added. My questions:- Can this 'add_comment' XMLRPC be made to work easily? Am I close? Or is there some reason why an 'add_comment' RPC is not possible at this time? Is there a 'trace' or 'log' for obtaining diagnostic/debugging messages from bugzilla while its running? sub add_comment { my ($self, $params) = @_; my $user = Bugzilla->login(LOGIN_REQUIRED); return { success => type('string')->value('Bad user!') } if ( ! defined( $user ) ); ValidateBugID($params->{bug}); my $bug = new Bugzilla::Bug($params->{bug}); return { success => type('string')->value('Bug not found!') } if ( ! defined( $user ) ); my $uid = $user->id; my $bid = $bug->bug_id; Bugzilla::Bug->AppendComment( $bid, $uid, $params->{comment} ); # Bugzilla::BugMail::Send($bug->bug_id, { changer => $bug->reporter->login }); return { success => type('string')->value('You betcha!') }; } Below is a fragment of perl that I am using to test it:- $xmlrpc_result = $proxy->call('User.login', { login => 'jeff.lasslett at datataker.com.au', password => 'password' } ); _die_on_fault($xmlrpc_result); $xmlrpc_result = $proxy->call('Bug.create', { product => "DT8x", component => "Firmware", summary => "TestBug 12 - created from exodus.pl", version => "6.18", description => "This is a description of the bug... hohoho", op_sys => "DT8x", platform => "All", priority => "P4", severity => "normal" } ); _die_on_fault($xmlrpc_result); $result = $xmlrpc_result->result; print "Added bug $$result{id}\n"; $xmlrpc_result = $proxy->call('Bug.add_comment', { bug => $$result{id}, comment => 'This is just a test bug comment!!' } ); _die_on_fault($xmlrpc_result); $result = $xmlrpc_result->result; #print( "uid:$$result{uid} bid:$$result{bid} msg:$$result{msg}\n" ); print "Did it work?? $$result{success}\n"; From mkanat at bugzilla.org Thu May 17 05:19:49 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 16 May 2007 22:19:49 -0700 Subject: Adding an XML-RPC to append comments In-Reply-To: <1179375876.13828.28.camel@jeff> References: <1179375876.13828.28.camel@jeff> Message-ID: <20070517052124.7D606118036@help.trusthosting.net> On Thu, 17 May 2007 14:24:36 +1000 Jeff Lasslett wrote: > Can this 'add_comment' XMLRPC be made to work easily? Am I > close? Or is there some reason why an 'add_comment' RPC is > not possible at this time? Well, there's a reason that it's not in 3.0. We need to fix the architecture of Bugzilla a bit and then we can make one. > Bugzilla::Bug->AppendComment( $bid, $uid, $params->{comment} ); AppendComment is not a method. Just call it as a subroutine. By the way, did you see this bug that has a patch to do what you want? https://bugzilla.mozilla.org/show_bug.cgi?id=355847 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jeff.lasslett at datataker.com.au Thu May 17 06:58:30 2007 From: jeff.lasslett at datataker.com.au (Jeff Lasslett) Date: Thu, 17 May 2007 16:58:30 +1000 Subject: Adding an XML-RPC to append comments In-Reply-To: <20070517052124.7D606118036@help.trusthosting.net> References: <1179375876.13828.28.camel@jeff> <20070517052124.7D606118036@help.trusthosting.net> Message-ID: <1179385110.15421.6.camel@jeff> Thanks Max, After patching the original (v3.0) Bug.pm with patch attachment #245546 My script produces the following when trying to call 'Bug.create': I don't see why Bugzilla::WebService::Bug can no longer be located. Can you please point me in the right direction? Thanks in advance. Client Failed to access class (Bugzilla::WebService::Bug): Can't locate Bugzilla/WebService/Bug.pm in @INC (@INC contains: . /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl) at (eval 123) line 3. in XMLRPC call near ./exodus.pl line 46. On Wed, 2007-05-16 at 22:19 -0700, Max Kanat-Alexander wrote: > On Thu, 17 May 2007 14:24:36 +1000 Jeff Lasslett > wrote: > > Can this 'add_comment' XMLRPC be made to work easily? Am I > > close? Or is there some reason why an 'add_comment' RPC is > > not possible at this time? > > Well, there's a reason that it's not in 3.0. We need to fix the > architecture of Bugzilla a bit and then we can make one. > > > Bugzilla::Bug->AppendComment( $bid, $uid, $params->{comment} ); > > AppendComment is not a method. Just call it as a subroutine. > > By the way, did you see this bug that has a patch to do what > you want? > > https://bugzilla.mozilla.org/show_bug.cgi?id=355847 > > -Max From lpsolit at gmail.com Thu May 17 10:21:16 2007 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Thu, 17 May 2007 12:21:16 +0200 Subject: Adding an XML-RPC to append comments In-Reply-To: <1179385110.15421.6.camel@jeff> References: <1179375876.13828.28.camel@jeff> <20070517052124.7D606118036@help.trusthosting.net> <1179385110.15421.6.camel@jeff> Message-ID: <464C2C9C.40204@gmail.com> > I don't see why Bugzilla::WebService::Bug can no longer be located. > > Can you please point me in the right direction? Could we keep support questions in the mozilla.support.bugzilla newsgroup? Thanks. LpSolit From aaron.trevena at gmail.com Thu May 17 16:27:37 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Thu, 17 May 2007 17:27:37 +0100 Subject: Module dependencies and packages In-Reply-To: References: <4649B933.4060403@mozilla.org> <4649EAC6.8000308@mozilla.org> <464B22A9.1060607@etlicon.fi> <464B54DD.5090208@bugzilla.org> Message-ID: On 16/05/07, Aaron Trevena wrote: > > Or roll your own RPMs. I tend to do that a lot. Most of the time > > building an RPM is pretty easy. And when you're running a couple > > hundred servers, it's a lifesaver to have a list of what the installed > > packages were to restore to a new machine with the data backups if a > > hard drive takes a nose-dive. > > Yeah. As it happens I'm rolling our stuff up into debian packages. > > cpanplus::dist::deb to the rescue using dpkg::parse to build an ignore list I now have a script which will generate ignorelist files for cpan2dist from perl core and debian dpkg available files. Packaging modules with cpan2dist that have lots of dependancies will now be a lot easier. Anybody else interested let me know. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From jeff.lasslett at datataker.com.au Thu May 17 22:47:29 2007 From: jeff.lasslett at datataker.com.au (Jeff Lasslett) Date: Fri, 18 May 2007 08:47:29 +1000 Subject: Adding an XML-RPC to append comments In-Reply-To: <464C2C9C.40204@gmail.com> References: <1179375876.13828.28.camel@jeff> <20070517052124.7D606118036@help.trusthosting.net> <1179385110.15421.6.camel@jeff> <464C2C9C.40204@gmail.com> Message-ID: <1179442049.5743.5.camel@jeff> On Thu, 2007-05-17 at 12:21 +0200, Fr?d?ric Buclin wrote: > > I don't see why Bugzilla::WebService::Bug can no longer be located. > > > > Can you please point me in the right direction? > > > Could we keep support questions in the mozilla.support.bugzilla > newsgroup? Thanks. Certainly, however I am mucking around with bugzilla code. I assume typical users don't do that. Specifically, I'm trying to get an 'append_comment' XMLRPC to work. Developers definitely seem to me to be the most appropriate people to ask. Especially since it seems that the feature has recently been added to the 3.1 code. I was just after a little help in trying to add a feature to my bugzilla installation. Cheers, Jeff From ja.lee at logicacmg.com Fri May 18 01:07:49 2007 From: ja.lee at logicacmg.com (Lee, Jarrad (Outsourcing)) Date: Fri, 18 May 2007 11:07:49 +1000 Subject: Setting default version for bug creation Message-ID: Hi, I'm making quite a few visual and UI modifications to a Bugzilla 3.0 installation. Currently I'm looking at making the 'Version' field set the latest (highest) version to 'selected' by default. I'm pretty certain what I need to change in create.html.tmpl is here... Version: For example if I have the versions (they show up in this order, with 'Pre 4.1.3' selected by default): 4.1.3 4.2.0 4.2.1 4.2.2 N/A Pre 4.1.3 In this case I would like 4.2.2 to be selected by default. I have no idea what default.version is or where to set it... Any ideas would be much appreciated. Cheers, Jarrad Lee This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Fri May 18 04:04:24 2007 From: justdave at bugzilla.org (David Miller) Date: Fri, 18 May 2007 00:04:24 -0400 Subject: Adding an XML-RPC to append comments In-Reply-To: <464C2C9C.40204@gmail.com> References: <1179375876.13828.28.camel@jeff> <20070517052124.7D606118036@help.trusthosting.net> <1179385110.15421.6.camel@jeff> <464C2C9C.40204@gmail.com> Message-ID: <464D25C8.6020004@bugzilla.org> Fr?d?ric Buclin wrote on 5/17/07 6:21 AM: >> I don't see why Bugzilla::WebService::Bug can no longer be located. >> >> Can you please point me in the right direction? > > > Could we keep support questions in the mozilla.support.bugzilla > newsgroup? Thanks. Sounded like a code question to me. (review on a patch?) The thread as a whole anyway. He's starting to head off, but we already know what he's talking about here, and the beginning of the thread would be irrelevant on the support list. He might contribute fixes to this patch once he gets it working, don't scare him away ;) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From lpsolit at gmail.com Sat May 19 22:04:18 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sun, 20 May 2007 00:04:18 +0200 Subject: Custom workflow (almost) implemented Message-ID: <464F7462.3090300@gmail.com> Hi all, I have (almost) implemented custom workflow in Bugzilla 3.1. I still have a few lines of code to fix, but it's mostly working. One thing I have to think about is what to do with this UNCONFIRMED/REOPENED behavior when reopening a closed bug ('closed' as in RESOLVED/VERIFIED/CLOSED). In Bugzilla 3.0 and older, if a bug has never been confirmed, reopening it will set its state to UNCONFIRMED, else to REOPENED. Now that you can set your own workflow, you could decide that RESOLVED -> REOPENED is allowed, but RESOLVED -> UNCONFIRMED is not. In this case, the UI in show_bug.cgi should display "Change status to REOPENED" even for bugs which have never been confirmed. On the other hand, if both -> UNCO and -> REOP are allowed, should the UI behave in the old way and only display the "correct" one based on everconfirmed, or assume that both should be displayed as both are present in the workflow? For consistency with Bugzilla 3.0 and older, I added a hack in the UI to only display the "correct" one (either UNCO or REOP, but not both). So if an admin disable RESOLVED -> UNCONFIRMED from the workflow and a bug has never been confirmed, nothing will be displayed in the UI to reopen it (because the status it expected to display (UNCO) is forbidden by the workflow). On the other hand, you could say: if one transition is forbidden, display the other one. But this is an even bigger hack. Also, if both transitions are allowed, how does Bugzilla know if you really expect the old behavior (select the correct one between UNCO and REOP) or if you want to see both (display both UNCO and REOP)? I thought it may be a good idea to have a new parameter to choose if you want the old or new behavior. If you select 'old', then Bugzilla will choose between UNCO and REOP. If you select 'new', Bugzilla will display *all* allowed transitions (so you could see both UNCO and REOP at the same time if your workflow says so). What is your opinion on it? LpSolit From mkanat at bugzilla.org Sat May 19 22:46:57 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 19 May 2007 15:46:57 -0700 Subject: Custom workflow (almost) implemented In-Reply-To: <464F7462.3090300@gmail.com> References: <464F7462.3090300@gmail.com> Message-ID: <20070519224836.AF30B118036@help.trusthosting.net> On Sun, 20 May 2007 00:04:18 +0200 Fr?d?ric Buclin wrote: > I thought it may be a good idea to have a new parameter to choose if > you want the old or new behavior. If you select 'old', then Bugzilla > will choose between UNCO and REOP. If you select 'new', Bugzilla will > display *all* allowed transitions (so you could see both UNCO and > REOP at the same time if your workflow says so). What is your opinion > on it? Yeah, I think it will have to be a separate parameter on the same page. Something like: When a bug is "reopened": (a) Set it to UNCONFIRMED if it was previously UNCONFIRMED, and REOPENED otherwise. (b) Set it to whatever its previous status was. And instead of having REOPENED as a status transition, we can have an action called "reopen" in the workflow, and what it does can be defined as above. And then people can also specify transitions to NEW and so on. "reopen" should only be allowed from closed states. Having a system like this, where certain status transitions are actually defined by a separate parameter, will allow us to have an even more flexible system. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mshapiro at mozilla.com Fri May 18 06:15:22 2007 From: mshapiro at mozilla.com (Melissa Shapiro) Date: Thu, 17 May 2007 23:15:22 -0700 Subject: Bugzilla in the news In-Reply-To: <4645CC19.7080407@bugzilla.org> References: <4645CC19.7080407@bugzilla.org> Message-ID: <464D447A.3050209@mozilla.com> Another one from SD Times: May 14 "Bugzilla 3.0 Released" - Alex Handy http://www.sdtimes.com/article/LatestNews-20070501-22.html David Miller wrote: > As of 7am Pacific, Saturday May 12: > > "Bugzilla 3.0 let loose upon the world" - srlinuxx > http://www.tuxmachines.org/node/16205 > > "Bugzilla 3.0 let loose upon the world" - Staff Writer > http://www.tectonic.co.za/view.php?id=1505 > > "More Bugs Quashed With Bugzilla 3.0" - Sean Michael Kerner > http://www.internetnews.com/dev-news/article.php/3677011 > > "More Bugs Quashed With Bugzilla 3.0" - tk421 > http://mobile.newsforge.com/newsvac/07/05/10/2148203.shtml > > "Bugzilla 3.0 Released" - no byline > http://www.mozillazine.org/talkback.html?article=21713 > > "After 9 years, Bugzilla moves up to 3.0" - Mayank Sharma > http://www.linux.com/article.pl?sid=07/05/12/0234203 > > "After 9 years, Bugzilla moves up to 3.0" - Mayank Sharma > http://trends.newsforge.com/trends/07/05/12/0233209.shtml > > "After 9 Years, Bugzilla Moves Up to 3.0" - Zonk / BuggyUser > http://it.slashdot.org/article.pl?sid=07/05/12/0641225 > > "Bugzilla 3.0 Released!" - zbraniecki > http://digg.com/software/Bugzilla_3_0_released > > "After NINE YEARS, Bugzilla moves up to 3.0 !" - estvir > http://digg.com/linux_unix/After_NINE_YEARS_Bugzilla_moves_up_to_3_0 > > "Why did it take bugzilla 9 years to get from version 2.0 to 3.0? - stu42j > http://digg.com/linux_unix/Why_did_it_take_Bugzilla_9_years_to_get_from_version_2_0_to_3_0 > > "More Bugs Quashed With Bugzilla 3.0" - Sean Michael Kerner > http://www.linuxtoday.com/news_story.php3?ltsn=2007-05-11-018-35-OS-SW-DV > > -- Melissa Shapiro PR Manager Mozilla Corporation o: 650-903-0800 x247 c: 415-595-3734 melissa at mozilla.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff.lasslett at datataker.com.au Mon May 21 01:04:25 2007 From: jeff.lasslett at datataker.com.au (Jeff Lasslett) Date: Mon, 21 May 2007 11:04:25 +1000 Subject: Adding an XML-RPC to append comments In-Reply-To: <464D25C8.6020004@bugzilla.org> References: <1179375876.13828.28.camel@jeff> <20070517052124.7D606118036@help.trusthosting.net> <1179385110.15421.6.camel@jeff> <464C2C9C.40204@gmail.com> <464D25C8.6020004@bugzilla.org> Message-ID: <1179709465.7229.22.camel@jeff> On Fri, 2007-05-18 at 00:04 -0400, David Miller wrote: > Fr?d?ric Buclin wrote on 5/17/07 6:21 AM: > > Could we keep support questions in the mozilla.support.bugzilla > > newsgroup? Thanks. > > Sounded like a code question to me. (review on a patch?) The thread as > a whole anyway. He's starting to head off, but we already know what > he's talking about here, and the beginning of the thread would be > irrelevant on the support list. > > He might contribute fixes to this patch once he gets it working, don't > scare him away ;) Thanks David. I have found a way around my problem. I went back to the v3.0 release version of Bugzilla/WebService/Bug.pm and then manually added the 'append_comment' function from the patch. That did the trick. Not much of a patch review I'm afraid. :-) The XML-RPC interface is perfect for migrating bugs from a 'home grown' bug tracker to bugzilla. I've needed add plenty of test bugs to my bugzilla installation during the course of developing my migration scripts. To easily remove these tests I added a 'Bug.remove' XML-RPC that removes a bug from the database. It's a wrapper around a routine I found in Bugzilla/Bug.pm called 'remove_from_db'. Bugs removed this way are removed properly and the DB stays sane. Attached is a patch that adds Bug.remove. Use -p5 option to patch. Cheers, Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: remove.patch Type: text/x-patch Size: 953 bytes Desc: not available URL: From mbd at dbc.dk Mon May 21 06:14:52 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Mon, 21 May 2007 08:14:52 +0200 Subject: Adding an XML-RPC to append comments In-Reply-To: <1179385110.15421.6.camel@jeff> References: <1179375876.13828.28.camel@jeff> <20070517052124.7D606118036@help.trusthosting.net> <1179385110.15421.6.camel@jeff> Message-ID: <200705210814.52489.mbd@dbc.dk> torsdag 17 maj 2007 08:58 skrev Jeff Lasslett: > Thanks Max, > > After patching the original (v3.0) Bug.pm with patch attachment #245546 > > My script produces the following when trying to call 'Bug.create': > > I don't see why Bugzilla::WebService::Bug can no longer be located. Risking the wrath of the gurus for answering this: I have found, that when using "patch", it often changes the status bits of the files. I usually need to chmod a bit to get it working again, or running the update script. And, while I am at it, you need to read: http://www.bugzilla.org/docs/contributor.html to understand the bugzilla "rules" on contributions. It will make it a lot easier for you! :-) Also, in order to get any patch for the XML-RPC accepted, you need to follow the rules for returning error codes, and you need to document the methods you add, following the rules for that! I know from experience, that it can take a while to get it rigth == getting a reviewer to approve. OTOH, there is no question that the sort-of rigid process improves the final result. One of these days I will fix the stuff the reviewer (Max) has pointed out in https://bugzilla.mozilla.org/show_bug.cgi?id=355847 - currently waiting for a bugzilla 3.0 update on our main installation... Regards, Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From jeff.lasslett at datataker.com.au Mon May 21 06:58:49 2007 From: jeff.lasslett at datataker.com.au (Jeff Lasslett) Date: Mon, 21 May 2007 16:58:49 +1000 Subject: Adding an XML-RPC to append comments In-Reply-To: <200705210814.52489.mbd@dbc.dk> References: <1179375876.13828.28.camel@jeff> <20070517052124.7D606118036@help.trusthosting.net> <1179385110.15421.6.camel@jeff> <200705210814.52489.mbd@dbc.dk> Message-ID: <1179730729.11128.10.camel@jeff> Thanks Mads, Next time I make a patch I will definitely follow the guidelines you've pointed out to me. I guess I was informally offering up that bit of code (Bug.remove). I don't mind if it's not used. :-) Thanks also for the tip re: file permissions and diff. I'll keep an eye out for that. :-) I did notice the disciplined approach to documentation in the patch 245546. Cheers, Jeff On Mon, 2007-05-21 at 08:14 +0200, Mads Bondo Dydensborg wrote: > torsdag 17 maj 2007 08:58 skrev Jeff Lasslett: > > Thanks Max, > > > > After patching the original (v3.0) Bug.pm with patch attachment #245546 > > > > My script produces the following when trying to call 'Bug.create': > > > > I don't see why Bugzilla::WebService::Bug can no longer be located. > > Risking the wrath of the gurus for answering this: I have found, that when > using "patch", it often changes the status bits of the files. I usually need > to chmod a bit to get it working again, or running the update script. > > And, while I am at it, you need to read: > http://www.bugzilla.org/docs/contributor.html > to understand the bugzilla "rules" on contributions. It will make it a lot > easier for you! :-) > > Also, in order to get any patch for the XML-RPC accepted, you need to follow > the rules for returning error codes, and you need to document the methods you > add, following the rules for that! I know from experience, that it can take a > while to get it rigth == getting a reviewer to approve. OTOH, there is no > question that the sort-of rigid process improves the final result. > > One of these days I will fix the stuff the reviewer (Max) has pointed out in > https://bugzilla.mozilla.org/show_bug.cgi?id=355847 > - currently waiting for a bugzilla 3.0 update on our main installation... > > Regards, > > Mads > From gerv at mozilla.org Mon May 21 11:22:41 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 21 May 2007 12:22:41 +0100 Subject: Custom workflow (almost) implemented In-Reply-To: <464F7462.3090300@gmail.com> References: <464F7462.3090300@gmail.com> Message-ID: <46518101.8060501@mozilla.org> A key point before I start: I believe it's an extremely important principle of the custom workflow design that, aside from being designated as "open" or "closed" (note: I am making a distinction between "closed" and CLOSED; the former is a class of statuses, the latter a particular status in that class), there should be no "special" states. That is, there should be no code in Bugzilla which references particular states by name. Fr?d?ric Buclin wrote: > I have (almost) implemented custom workflow in Bugzilla 3.1. I still > have a few lines of code to fix, but it's mostly working. One thing I > have to think about is what to do with this UNCONFIRMED/REOPENED > behavior when reopening a closed bug ('closed' as in > RESOLVED/VERIFIED/CLOSED). My proposal: we do not make the state of reopened bugs dependent on their previous opened state. In other words, we abandon the "everconfirmed" flag. In specific terms, using the workflow we have today, that would mean that bugs would always go to REOPENED, and never to UNCONFIRMED. I think this is the right thing to do for several reasons. The first is that it preserves the principle I outline at the top, thereby simplifying both the implementation and the model in the user's mind of how custom workflow works. It also makes good sense. As it's now possible to change resolutions while a bug is closed, that means that if you are reopening a bug, it must be because you want someone to work on it some more - i.e. you have some information that it is a bug. So UNCONFIRMED is inappropriate. Under the current workflow, there is no way to re-enter UNCONFIRMED, and so this feature has some possible uses. With a custom workflow, that no longer has to be the case. If people want to be able to take occasional bugs back to UNCONFIRMED based on the quality of the bug report, they can enable the REOPENED -> UNCONFIRMED transition. But this decision should be based on the information in the report, rather than the previous state. It would be interesting to see how many bugs in b.m.o. were reopened and set back to UNCONFIRMED by the everconfirmed flag, only for the triager to have to go in and change it to NEW. Gerv From Nick.Barnes at pobox.com Mon May 21 12:17:34 2007 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 21 May 2007 13:17:34 +0100 Subject: Custom workflow (almost) implemented In-Reply-To: <46518101.8060501@mozilla.org> from Gervase Markham of "Mon, 21 May 2007 12:22:41 +0100" Message-ID: <81237.1179749854@thrush.ravenbrook.com> At 2007-05-21 11:22:41+0000, Gervase Markham writes: > In specific terms, using the workflow we have today, that would mean > that bugs would always go to REOPENED, and never to UNCONFIRMED. I think this is obviously The Right Thing. Nick B From gerv at mozilla.org Mon May 21 15:01:56 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 21 May 2007 16:01:56 +0100 Subject: [Fwd: Feature focus - status/keywords/flags/fields] In-Reply-To: <464A0E0F.4050006@mozilla.org> References: <464996B4.8050200@mozilla.org> <464A0E0F.4050006@mozilla.org> Message-ID: <4651B464.9090901@mozilla.org> Myk Melez wrote: > Max then agreed with Dave > that we should do forwarding, despite not wanting to switch from > developers at bugzilla.org to > dev-apps-bugzilla at lists.mozilla.org > (although it's not clear > that forwarding actually requires this). OK. So let's do this. What's next? Is this something Dave does or do we file a bug on the support team? Gerv From justdave at bugzilla.org Mon May 21 15:51:01 2007 From: justdave at bugzilla.org (David Miller) Date: Mon, 21 May 2007 11:51:01 -0400 Subject: [Fwd: Feature focus - status/keywords/flags/fields] In-Reply-To: <4651B464.9090901@mozilla.org> References: <464996B4.8050200@mozilla.org> <464A0E0F.4050006@mozilla.org> <4651B464.9090901@mozilla.org> Message-ID: <4651BFE5.70206@bugzilla.org> Gervase Markham wrote on 5/21/07 11:01 AM: > Myk Melez wrote: >> Max then agreed with Dave that we should do forwarding, despite not >> wanting to switch from developers at bugzilla.org to >> dev-apps-bugzilla at lists.mozilla.org (although it's not clear >> that forwarding actually requires this). > > OK. So let's do this. What's next? Is this something Dave does or do we > file a bug on the support team? both. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From gerv at mozilla.org Tue May 22 10:16:26 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 22 May 2007 11:16:26 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <46483D24.5010802@mozilla.org> References: <46483D24.5010802@mozilla.org> Message-ID: <4652C2FA.2080200@mozilla.org> Gervase Markham wrote: > I'm not sure there's much we can do about this. The spammer obviously > took time to create an account - perhaps automatically, perhaps not. > Short of implementing Captchas for account signup, or refusing to > display HTML attachments as HTML, I can't see a counter. > > Thoughts? Someone on my blog suggested requiring a login to view attachments. That seems to me like a possible solution. We would need to make it so that, in this one particular case, you couldn't login automatically using URL parameters - otherwise the spammer would just use the login details for the account they used to upload the spam. We could do this by deleting the relevant parameter names before calling login(). Who would that inconvenience? Perhaps people who have automated systems which download Bugzilla attachments? Gerv From gerv at mozilla.org Tue May 22 15:38:59 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 22 May 2007 16:38:59 +0100 Subject: Bugzilla installation list and SEO Message-ID: <46530E93.1000107@mozilla.org> My (with 20/20 hindsight, foolish) post about the Bugzilla Installation List and Pagerank has led to several shady applications in the past few weeks, mostly from Poland. Possible example: http://www.profesjonalna-reklama.pl/ (check the footer carefully) Would it be reasonable to say that: 1) The link text for companies is always the name of the company 2) We treat companies which apply with "suggestions" for link text with deep suspicion 3) We don't link to pages which have sponsored links ? Gerv From jpyeron at pdinc.us Tue May 22 15:45:12 2007 From: jpyeron at pdinc.us (Jason Pyeron) Date: Tue, 22 May 2007 11:45:12 -0400 Subject: Bugzilla installation list and SEO In-Reply-To: <46530E93.1000107@mozilla.org> Message-ID: <004e01c79c88$352cc400$5201a8c0@MRSLAPTOP> Not sure what I am looking for in the footer? Is there something to indicate that they do not have a bz install? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Sr. Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: Tuesday, May 22, 2007 11:39 To: developers at bugzilla.org Subject: Bugzilla installation list and SEO My (with 20/20 hindsight, foolish) post about the Bugzilla Installation List and Pagerank has led to several shady applications in the past few weeks, mostly from Poland. Possible example: http://www.profesjonalna-reklama.pl/ (check the footer carefully) Would it be reasonable to say that: 1) The link text for companies is always the name of the company 2) We treat companies which apply with "suggestions" for link text with deep suspicion 3) We don't link to pages which have sponsored links ? Gerv - To view or change your list settings, click here: From gerv at mozilla.org Tue May 22 15:55:50 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 22 May 2007 16:55:50 +0100 Subject: Bugzilla installation list and SEO In-Reply-To: <004e01c79c88$352cc400$5201a8c0@MRSLAPTOP> References: <004e01c79c88$352cc400$5201a8c0@MRSLAPTOP> Message-ID: <46531286.90909@mozilla.org> Jason Pyeron wrote: > Not sure what I am looking for in the footer? > > Is there something to indicate that they do not have a bz install? The paid links to other sites. Gerv From lpsolit at gmail.com Tue May 22 16:33:11 2007 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 22 May 2007 18:33:11 +0200 Subject: Using Bugzilla to hide spam sites In-Reply-To: <4652C2FA.2080200@mozilla.org> References: <46483D24.5010802@mozilla.org> <4652C2FA.2080200@mozilla.org> Message-ID: <46531B47.2020102@gmail.com> > Someone on my blog suggested requiring a login to view attachments. That > seems to me like a possible solution. Really not! Why should *we* have to log in because someone *else* attaches unwanted attachments? This is annoying and I frequently view attachments without being logged in (e.g. when being on computers which are not mine). I would hate to not be allowed to view them anymore. LpSolit From myk at mozilla.org Tue May 22 20:53:42 2007 From: myk at mozilla.org (Myk Melez) Date: Tue, 22 May 2007 22:53:42 +0200 Subject: Bugzilla installation list and SEO In-Reply-To: <46530E93.1000107@mozilla.org> References: <46530E93.1000107@mozilla.org> Message-ID: <46535856.4040201@mozilla.org> Gervase Markham wrote: > 1) The link text for companies is always the name of the company > > 2) We treat companies which apply with "suggestions" for link text > with deep suspicion > > 3) We don't link to pages which have sponsored links I think we should go farther than this and remove links to all companies that don't have a public installation that we can link to directly. We can still leave their name there, but we should remove the links. Otherwise there's a strong incentive for companies to say they have a Bugzilla installation when they don't, and policing each applicant is going to take way more time than it's worth. -myk From djm at mindrot.org Wed May 23 00:43:10 2007 From: djm at mindrot.org (Damien Miller) Date: Wed, 23 May 2007 10:43:10 +1000 (EST) Subject: Bugzilla installation list and SEO In-Reply-To: <46530E93.1000107@mozilla.org> References: <46530E93.1000107@mozilla.org> Message-ID: On Tue, 22 May 2007, Gervase Markham wrote: > My (with 20/20 hindsight, foolish) post about the Bugzilla Installation List > and Pagerank has led to several shady applications in the past few weeks, > mostly from Poland. Possible example: http://www.profesjonalna-reklama.pl/ > (check the footer carefully) > > Would it be reasonable to say that: > > 1) The link text for companies is always the name of the company > > 2) We treat companies which apply with "suggestions" for link text with deep > suspicion > > 3) We don't link to pages which have sponsored links 4) Mark all the links with rel="nofollow" so they don't contribute to SEO success. #4 is what OpenBSD has done for its donations page. -d From gerv at mozilla.org Wed May 23 16:12:20 2007 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 May 2007 17:12:20 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <46531B47.2020102@gmail.com> References: <46483D24.5010802@mozilla.org> <4652C2FA.2080200@mozilla.org> <46531B47.2020102@gmail.com> Message-ID: <465467E4.40509@mozilla.org> Fr?d?ric Buclin wrote: >> Someone on my blog suggested requiring a login to view attachments. >> That seems to me like a possible solution. > > Really not! Why should *we* have to log in because someone *else* > attaches unwanted attachments? Why should we have to keep filling in captchas to sign up for things or post blog comments just because other people post spam? :-| It's just the way it is. Do you have a less intrusive solution? > This is annoying and I frequently view > attachments without being logged in (e.g. when being on computers which > are not mine). I would hate to not be allowed to view them anymore. You can. You just need to log in. It seems to me that most Bugzilla users spend most of their Bugzilla time logged in. Would others agree? Gerv From lpsolit at gmail.com Wed May 23 16:19:09 2007 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 23 May 2007 18:19:09 +0200 Subject: Using Bugzilla to hide spam sites In-Reply-To: <465467E4.40509@mozilla.org> References: <46483D24.5010802@mozilla.org> <4652C2FA.2080200@mozilla.org> <46531B47.2020102@gmail.com> <465467E4.40509@mozilla.org> Message-ID: <4654697D.6040409@gmail.com> > Why should we have to keep filling in captchas to sign up for things or > post blog comments just because other people post spam? :-| It's just > the way it is. I don't like captchas either. I much prefer using the text/plain MIME instead of text/html for users with no privs. And if IE6 is unable to respect that, then that's not our problem anymore (I'm a bit rude here, but Firefox (and Opera) users shouldn't have to pay for IE users). LpSolit From gerv at mozilla.org Wed May 23 16:24:27 2007 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 May 2007 17:24:27 +0100 Subject: Bugzilla installation list and SEO In-Reply-To: <46535856.4040201@mozilla.org> References: <46530E93.1000107@mozilla.org> <46535856.4040201@mozilla.org> Message-ID: <46546ABB.9050403@mozilla.org> Myk Melez wrote: > I think we should go farther than this and remove links to all companies > that don't have a public installation that we can link to directly. > > We can still leave their name there, but we should remove the links. > Otherwise there's a strong incentive for companies to say they have a > Bugzilla installation when they don't, and policing each applicant is > going to take way more time than it's worth. That would be sad. Before I was stupid enough to make it public, I thought of the small pagerank boost we gave companies which used Bugzilla as a way to say "thankyou". I don't think this has happened in the past - all the emails I get have a real ring of genuineness. I think I might start with being deeply sceptical, and if that doesn't work, we can add rel=nofollow to new ones or suspect ones. Gerv From gerv at mozilla.org Wed May 23 16:47:34 2007 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 May 2007 17:47:34 +0100 Subject: Using Bugzilla to hide spam sites In-Reply-To: <4654697D.6040409@gmail.com> References: <46483D24.5010802@mozilla.org> <4652C2FA.2080200@mozilla.org> <46531B47.2020102@gmail.com> <465467E4.40509@mozilla.org> <4654697D.6040409@gmail.com> Message-ID: <46547026.8050606@mozilla.org> Fr?d?ric Buclin wrote: > I don't like captchas either. I much prefer using the text/plain MIME > instead of text/html for users with no privs. And if IE6 is unable to > respect that, then that's not our problem anymore (I'm a bit rude here, > but Firefox (and Opera) users shouldn't have to pay for IE users). I would happily agree with you. Except that it's not the IE users that suffer. It's the Bugzilla administrators who find their Bugzilla on spam blacklists, and their databases filled with rubbish. If Bugzilla attachment URLs in spam still work for a substantial proportion of internet users, spammers will continue to use them, and the problem will not be solved. It might be that making them not work in Firefox/Opera/Safari is enough - but I don't think there's any way to be sure of that. Gerv From dwilliss at microimages.com Thu May 24 13:58:49 2007 From: dwilliss at microimages.com (Dave Williss) Date: Thu, 24 May 2007 08:58:49 -0500 Subject: Bugzilla 3.0 update experience Message-ID: <46559A19.1000404@microimages.com> We just upgraded our Bugzilla instillation from 2.22 to 3.0 yesterday. It looks great! We immediately added a custom field. In fact, the ability to do that is what prompted the upgrade. I also like the no more accidentally submitting the same bug twice fix. I know I've been guilty of that on several occasions. Just closing and reopening Firefox after submitting a bug would do it when Firefox restored the session. Glad to see that one solved. About the only problem we had was that Firefox users had to clear their browser cache or it tried to render the page with a cached style sheet from 2.22 and everything looked really ugly. The only real installation problem I had was trying to get all the Perl modules installed onto a machine which is on a private LAN physically isolated from the Internet (so cpan doesn't help). The bugzilla site lists the Perl modules that it requires, but for some of those I had to follow dependencys three or four levels deep. I don't think anything can really be done about that though. David Williss Software Engineer MicroImages, Inc. From aaron.trevena at gmail.com Thu May 24 14:00:32 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Thu, 24 May 2007 15:00:32 +0100 Subject: Bugzilla 3.0 update experience In-Reply-To: <46559A19.1000404@microimages.com> References: <46559A19.1000404@microimages.com> Message-ID: On 24/05/07, Dave Williss wrote: > The only real installation problem I had was trying to get all the Perl > modules installed onto a machine which is on a private LAN physically > isolated from the Internet (so cpan doesn't help). The bugzilla site > lists the Perl modules that it requires, but for some of those I had to > follow dependencys three or four levels deep. I don't think anything > can really be done about that though. It should be possible to build a distro specific bundle with the required libraries bundled in or a PAR archive for that situation. Bundling a copy of PAR into bugzilla could make installation a whole lot easier. A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From dwilliss at microimages.com Thu May 24 14:04:35 2007 From: dwilliss at microimages.com (Dave Williss) Date: Thu, 24 May 2007 09:04:35 -0500 Subject: XMLRPC interface question Message-ID: <46559B73.3030807@microimages.com> Is there any documentation for the XMLPRC interface? All I can find is documentation of the Perl side, and it's not really even very complete. I'm looking for documentation from the end user side. Is this a SOAP interface? Is there a query to get the WSDL document that describes what methods are available? Dave Williss Software Engineer MicroImages, Inc. From mkanat at bugzilla.org Thu May 24 20:54:06 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 24 May 2007 13:54:06 -0700 Subject: XMLRPC interface question In-Reply-To: <46559B73.3030807@microimages.com> References: <46559B73.3030807@microimages.com> Message-ID: <20070524205551.18304118053@help.trusthosting.net> On Thu, 24 May 2007 09:04:35 -0500 Dave Williss wrote: > Is there any documentation for the XMLPRC interface? Yes, it's the various Bugzilla::WebService modules that are listed here: http://www.bugzilla.org/docs/tip/html/api/ Those *are* the WebService docs. That's the whole WebService, as of now. > I'm looking for documentation from the end user side. Is this a > SOAP interface? No. It's an XML-RPC interface. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From myk at mozilla.org Thu May 24 23:16:10 2007 From: myk at mozilla.org (Myk Melez) Date: Fri, 25 May 2007 01:16:10 +0200 Subject: Bugzilla installation list and SEO In-Reply-To: <46546ABB.9050403@mozilla.org> References: <46530E93.1000107@mozilla.org> <46535856.4040201@mozilla.org> <46546ABB.9050403@mozilla.org> Message-ID: <46561CBA.1030608@mozilla.org> Gervase Markham wrote: > That would be sad. Before I was stupid enough to make it public, I > thought of the small pagerank boost we gave companies which used > Bugzilla as a way to say "thankyou". Yes, it is unfortunate that a good gesture like this would get abused. FWIW, Mozdev recently stopped linking to donors . > I don't think this has happened in the past - all the emails I get > have a real ring of genuineness. I think I might start with being > deeply sceptical, and if that doesn't work, we can add rel=nofollow to > new ones or suspect ones. If you're willing to do that work, then it's fine with me to stick with the current policy. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From ja.lee at logicacmg.com Fri May 25 04:35:17 2007 From: ja.lee at logicacmg.com (Lee, Jarrad (Outsourcing)) Date: Fri, 25 May 2007 14:35:17 +1000 Subject: Setting default version for bug creation References: Message-ID: Well I had a less than overwhelming response to this problem. None the less I have found a solution without having to modify Bugzilla... I'm not sure whether this is Bugzilla functionality or not but if you prefix a product version with a blank space (e.g. ' 4.2.2') the version will be selected by default when you navigate to the page, it will appear in the list without the space and in it's correct numeric order in the list. Jarrad ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Lee, Jarrad (Outsourcing) Sent: Friday, 18 May 2007 11:08 AM To: developers at bugzilla.org Subject: Setting default version for bug creation Hi, I'm making quite a few visual and UI modifications to a Bugzilla 3.0 installation. Currently I'm looking at making the 'Version' field set the latest (highest) version to 'selected' by default. I'm pretty certain what I need to change in create.html.tmpl is here... Version: For example if I have the versions (they show up in this order, with 'Pre 4.1.3' selected by default): 4.1.3 4.2.0 4.2.1 4.2.2 N/A Pre 4.1.3 In this case I would like 4.2.2 to be selected by default. I have no idea what default.version is or where to set it... Any ideas would be much appreciated. Cheers, Jarrad Lee This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ja.lee at logicacmg.com Fri May 25 04:44:29 2007 From: ja.lee at logicacmg.com (Lee, Jarrad (Outsourcing)) Date: Fri, 25 May 2007 14:44:29 +1000 Subject: Setting default version for bug creation References: Message-ID: Ok scratch that, doesn't seem to be as easy as that... For some reason though version is now defaulting to the one I want for one product... maybe I inadvertently set this mysterious default.version somehow...? ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Lee, Jarrad (Outsourcing) Sent: Friday, 25 May 2007 2:35 PM To: developers at bugzilla.org Subject: Re: Setting default version for bug creation Well I had a less than overwhelming response to this problem. None the less I have found a solution without having to modify Bugzilla... I'm not sure whether this is Bugzilla functionality or not but if you prefix a product version with a blank space (e.g. ' 4.2.2') the version will be selected by default when you navigate to the page, it will appear in the list without the space and in it's correct numeric order in the list. Jarrad ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Lee, Jarrad (Outsourcing) Sent: Friday, 18 May 2007 11:08 AM To: developers at bugzilla.org Subject: Setting default version for bug creation Hi, I'm making quite a few visual and UI modifications to a Bugzilla 3.0 installation. Currently I'm looking at making the 'Version' field set the latest (highest) version to 'selected' by default. I'm pretty certain what I need to change in create.html.tmpl is here... Version: For example if I have the versions (they show up in this order, with 'Pre 4.1.3' selected by default): 4.1.3 4.2.0 4.2.1 4.2.2 N/A Pre 4.1.3 In this case I would like 4.2.2 to be selected by default. I have no idea what default.version is or where to set it... Any ideas would be much appreciated. Cheers, Jarrad Lee This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ja.lee at logicacmg.com Fri May 25 05:45:11 2007 From: ja.lee at logicacmg.com (Lee, Jarrad (Outsourcing)) Date: Fri, 25 May 2007 15:45:11 +1000 Subject: Setting default version for bug creation References: Message-ID: # IF this is a cloned bug, # AND the clone's product is the same as the parent's # THEN use the version from the parent bug # ELSE IF a version is supplied in the URL # THEN use it # ELSE IF there is a version in the cookie # THEN use it (Posting a bug sets a cookie for the current version.) # ELSE # The default version is the last one in the list (which, it is # hoped, will be the most recent one). # # Eventually maybe each product should have a "current version" # parameter. $vars->{'version'} = [map($_->name, @{$product->versions})]; if ( ($cloned_bug_id) && ($product->name eq $cloned_bug->product ) ) { $default{'version'} = $cloned_bug->{'version'}; } elsif (formvalue('version')) { $default{'version'} = formvalue('version'); } elsif (defined $cgi->cookie("VERSION-" . $product->name) && lsearch($vars->{'version'}, $cgi->cookie("VERSION-" . $product->name)) != -1) { $default{'version'} = $cgi->cookie("VERSION-" . $product->name); } else { $default{'version'} = $vars->{'version'}->[$#{$vars->{'version'}}]; } Looks like all the answers to my questions are in here (enter_bug.cgi). Sorry for the spam! But I do agree with "Eventually maybe each product should have a "current version" parameter." Jarrad. ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Lee, Jarrad (Outsourcing) Sent: Friday, 25 May 2007 2:44 PM To: developers at bugzilla.org Subject: Re: Setting default version for bug creation Ok scratch that, doesn't seem to be as easy as that... For some reason though version is now defaulting to the one I want for one product... maybe I inadvertently set this mysterious default.version somehow...? ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Lee, Jarrad (Outsourcing) Sent: Friday, 25 May 2007 2:35 PM To: developers at bugzilla.org Subject: Re: Setting default version for bug creation Well I had a less than overwhelming response to this problem. None the less I have found a solution without having to modify Bugzilla... I'm not sure whether this is Bugzilla functionality or not but if you prefix a product version with a blank space (e.g. ' 4.2.2') the version will be selected by default when you navigate to the page, it will appear in the list without the space and in it's correct numeric order in the list. Jarrad ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Lee, Jarrad (Outsourcing) Sent: Friday, 18 May 2007 11:08 AM To: developers at bugzilla.org Subject: Setting default version for bug creation Hi, I'm making quite a few visual and UI modifications to a Bugzilla 3.0 installation. Currently I'm looking at making the 'Version' field set the latest (highest) version to 'selected' by default. I'm pretty certain what I need to change in create.html.tmpl is here... Version: For example if I have the versions (they show up in this order, with 'Pre 4.1.3' selected by default): 4.1.3 4.2.0 4.2.1 4.2.2 N/A Pre 4.1.3 In this case I would like 4.2.2 to be selected by default. I have no idea what default.version is or where to set it... Any ideas would be much appreciated. Cheers, Jarrad Lee This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla at joostdevalk.nl Fri May 25 06:42:47 2007 From: bugzilla at joostdevalk.nl (Joost de Valk) Date: Fri, 25 May 2007 08:42:47 +0200 Subject: Bugzilla installation list and SEO In-Reply-To: <46546ABB.9050403@mozilla.org> References: <46530E93.1000107@mozilla.org> <46535856.4040201@mozilla.org> <46546ABB.9050403@mozilla.org> Message-ID: <46568567.4080900@joostdevalk.nl> Gervase Markham wrote: > Myk Melez wrote: >> I think we should go farther than this and remove links to all >> companies that don't have a public installation that we can link to >> directly. >> >> We can still leave their name there, but we should remove the links. >> Otherwise there's a strong incentive for companies to say they have a >> Bugzilla installation when they don't, and policing each applicant is >> going to take way more time than it's worth. > > That would be sad. Before I was stupid enough to make it public, I > thought of the small pagerank boost we gave companies which used > Bugzilla as a way to say "thankyou". > > I don't think this has happened in the past - all the emails I get > have a real ring of genuineness. I think I might start with being > deeply sceptical, and if that doesn't work, we can add rel=nofollow to > new ones or suspect ones. > > Gerv Hi guys, I feel urged to offer my assistance here... Next to doing some work on the Webkit project, I'm a fulltime SEO so perhaps I can help you guys come up with a solution? If you follow the Google guidelines on this sort of thing strictly, these outgoing links should be nofollowed, as you are not able to verify the authenticity of the claim they made. And I think, looking at the list, that there are some companies who have been using this already for some heavy linkbuilding... So my suggestion would be: add nofollow to the company listings... Joost -- Joost de Valk @: joost at joostdevalk.nl W: http://www.joostdevalk.nl "Never be afraid to try something new. Remember, amateurs built the ark, and professionals built the Titanic." From gerv at mozilla.org Fri May 25 14:43:21 2007 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 May 2007 15:43:21 +0100 Subject: Bugzilla installation list and SEO In-Reply-To: <46568567.4080900@joostdevalk.nl> References: <46530E93.1000107@mozilla.org> <46535856.4040201@mozilla.org> <46546ABB.9050403@mozilla.org> <46568567.4080900@joostdevalk.nl> Message-ID: <4656F609.5070301@mozilla.org> Joost de Valk wrote: > I feel urged to offer my assistance here... Next to doing some work on > the Webkit project, I'm a fulltime SEO so perhaps I can help you guys > come up with a solution? If you follow the Google guidelines on this > sort of thing strictly, these outgoing links should be nofollowed, as > you are not able to verify the authenticity of the claim they made. I think we can assume that all the ones before I made my post were legitimate. It may seem unfair, but it's normally fairly easy to tell which applications are dodgy. (I'm loath to reveal how, unless they read even this, but it is obvious.) > And > I think, looking at the list, that there are some companies who have > been using this already for some heavy linkbuilding... So my suggestion > would be: add nofollow to the company listings... I think there's one dodgy one in there at the moment - how many do you think there are? Related note: I've also noted spams using imageshack recently. Gerv From lpsolit at gmail.com Sat May 26 18:55:39 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sat, 26 May 2007 20:55:39 +0200 Subject: Minutes of the last Bugzilla meeting (May 15th) Message-ID: <465882AB.5070906@gmail.com> http://wiki.mozilla.org/Bugzilla:Meetings:2007-05-15 LpSolit From mbd at dbc.dk Sun May 27 19:07:22 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Sun, 27 May 2007 21:07:22 +0200 Subject: XMLRPC interface question In-Reply-To: <46559B73.3030807@microimages.com> References: <46559B73.3030807@microimages.com> Message-ID: <200705272107.22819.mbd@dbc.dk> torsdag 24 maj 2007 16:04 skrev Dave Williss: > Is there any documentation for the XMLPRC interface? > All I can find is documentation of the Perl side, and it's not really > even very complete. Apart from what Max writes, please note also that there are a number of example client programs in the contrib directory. Also, I can't help but mention the C# client library at http://sourceforge.net/projects/bugzproxy/ (disclaimer: I wrote it, and it seems the real homepage is down right now, but it will be up in a couple of days) Regards, Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From gerv at mozilla.org Mon May 28 11:40:36 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 28 May 2007 12:40:36 +0100 Subject: [Fwd: Feature focus - status/keywords/flags/fields] In-Reply-To: <4651BFE5.70206@bugzilla.org> References: <464996B4.8050200@mozilla.org> <464A0E0F.4050006@mozilla.org> <4651B464.9090901@mozilla.org> <4651BFE5.70206@bugzilla.org> Message-ID: <465ABFB4.3030809@mozilla.org> David Miller wrote: > Gervase Markham wrote on 5/21/07 11:01 AM: >> Myk Melez wrote: >>> Max then agreed with Dave that we should do forwarding, despite not >>> wanting to switch from developers at bugzilla.org to >>> dev-apps-bugzilla at lists.mozilla.org (although it's not clear >>> that forwarding actually requires this). >> OK. So let's do this. What's next? Is this something Dave does or do we >> file a bug on the support team? > > both. https://bugzilla.mozilla.org/show_bug.cgi?id=382231 filed. Gerv From ycombarnous at yahoo.fr Mon May 28 09:09:45 2007 From: ycombarnous at yahoo.fr (Barns) Date: Mon, 28 May 2007 02:09:45 -0700 (PDT) Subject: Minutes of the last Bugzilla meeting (May 15th) In-Reply-To: <465882AB.5070906@gmail.com> References: <465882AB.5070906@gmail.com> Message-ID: <10833153.post@talk.nabble.com> Anything planned about mod_perl memory usage enhancement/predictability in 3.2 (ie bypassing Size::Limit trick to make mod_perl usage possible on Windows) ? Fr?d?ric Buclin wrote: > > http://wiki.mozilla.org/Bugzilla:Meetings:2007-05-15 > > LpSolit > - > To view or change your list settings, click here: > > > -- View this message in context: http://www.nabble.com/Minutes-of-the-last-Bugzilla-meeting-%28May-15th%29-tf3821510.html#a10833153 Sent from the Bugzilla - Dev mailing list archive at Nabble.com. From gerv at mozilla.org Tue May 29 13:59:20 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 29 May 2007 14:59:20 +0100 Subject: Relationships between bugs Message-ID: <465C31B8.6040106@mozilla.org> developers, In mozilla.dev.planning, people were lamenting that it's difficult to correctly show that one bug was a regression caused by the checkin for another. Neither "blocks" nor "depends on" are entirely appropriate. A (proprietary) bug system I've used in the past has, instead of just dependencies, the more general concept of relationships: you give a bug number, and then say if it's blocking, blocks, regression, duplicate or just related. (We wouldn't use "duplicate", of course.) shaver rather liked this idea. Is this worth considering? We could also use this mechanism to remember that a bug was a clone of another, or perhaps that two bugs were for the same underlying problem but on two different code branches. The UI could be simplified to show only those lines where there was actually a bug in that relationship: Depends on: 12345, 34556 Clones: 65433 Branches: 75347 (1.3.1), 84346 (1.2.9) Add relationship: this bug [ blocks |V] bug(s): [ ] where the "blocks" dropdown could be "blocks", "depends on", "is a branch version of", "is related to", "was caused by checkin from" etc. You could still plot dependency graphs using the "blocking" and "blocks" relationships as we do now. What do you guys think? Gerv From dwilliss at microimages.com Tue May 29 14:06:15 2007 From: dwilliss at microimages.com (Dave Williss) Date: Tue, 29 May 2007 09:06:15 -0500 Subject: Problem with Bugzilla 3.0 and Firefox Message-ID: <465C3357.3030909@microimages.com> After upgrading to bugzilla 3.0, Firefox users have complained that sometimes the page is "messed up". At first, we attributed this to having cached the old css file, and clearing the cache fixed most of the issues. There is, however, one issue that remains. After submitting changes to a bug, the "People" section *sometimes* overlaps the "Details" section by about an inch. I'm not sure if this is a problem with Bugzilla or Firefox. Except for title and the "Changes submitted" section, the pages look like they should be identical. Examining a diff of the two pages seems to confirm that. The only difference in the html after the "Bug List" line is a URL at the bottom. Dave Williss Software Engineer MicroImages, Inc. From wicked at etlicon.fi Tue May 29 14:13:42 2007 From: wicked at etlicon.fi (Teemu Mannermaa) Date: Tue, 29 May 2007 17:13:42 +0300 Subject: Problem with Bugzilla 3.0 and Firefox In-Reply-To: <465C3357.3030909@microimages.com> References: <465C3357.3030909@microimages.com> Message-ID: <465C3516.6060904@etlicon.fi> On 29.05.2007 17:05, Dave Williss wrote: > After submitting changes to a bug, the "People" section *sometimes* > overlaps the "Details" section by about an inch. I'm not sure if this Sounds like you are hitting bug 370739 (https://bugzilla.mozilla.org/show_bug.cgi?id=370739). -- Teemu Mannermaa System Specialist "Anything is possible. It's all about probabilities." From justdave at bugzilla.org Tue May 29 14:27:24 2007 From: justdave at bugzilla.org (David Miller) Date: Tue, 29 May 2007 10:27:24 -0400 Subject: Relationships between bugs In-Reply-To: <465C31B8.6040106@mozilla.org> References: <465C31B8.6040106@mozilla.org> Message-ID: <465C384C.8040907@bugzilla.org> Gervase Markham wrote on 5/29/07 9:59 AM: > Depends on: 12345, 34556 > Clones: 65433 > Branches: 75347 (1.3.1), 84346 (1.2.9) > > Add relationship: this bug [ blocks |V] bug(s): [ ] > > where the "blocks" dropdown could be "blocks", "depends on", "is a > branch version of", "is related to", "was caused by checkin from" etc. > > You could still plot dependency graphs using the "blocking" and "blocks" > relationships as we do now. > > What do you guys think? Sounds intriguing. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From lpsolit at gmail.com Tue May 29 14:41:34 2007 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 29 May 2007 16:41:34 +0200 Subject: Relationships between bugs In-Reply-To: <465C31B8.6040106@mozilla.org> References: <465C31B8.6040106@mozilla.org> Message-ID: <465C3B9E.5000308@gmail.com> Gervase Markham a ?crit : > What do you guys think? Looks like you want something like bug 12286 or bug 251556. Our idea is to implement custom fields where you can have a list of bug IDs, and let the admin choose the name of the field ("regression" if you want to), see bug 287334. LpSolit From gerv at mozilla.org Tue May 29 15:35:31 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 29 May 2007 16:35:31 +0100 Subject: Relationships between bugs In-Reply-To: <465C3B9E.5000308@gmail.com> References: <465C31B8.6040106@mozilla.org> <465C3B9E.5000308@gmail.com> Message-ID: <465C4843.7060105@mozilla.org> Fr?d?ric Buclin wrote: > Gervase Markham a ?crit : >> What do you guys think? > > Looks like you want something like bug 12286 or bug 251556. Yes; these are similar. > Our idea is > to implement custom fields where you can have a list of bug IDs, and let > the admin choose the name of the field ("regression" if you want to), > see bug 287334. I don't think a custom field is the right solution. IMO, custom fields are best when they are information that pertains only to a single bug, and which has no special display requirements. "Customer name", that sort of thing. Dependencies link bugs together, and have special display requirements (dependencytree.cgi and dependencygraph.cgi). This makes me think that a general system for relating bugs together should be part of the core code. Just because we have the custom fields hammer, doesn't mean that this is a nail :-) Gerv From henry.story at bblfish.net Tue May 29 17:10:43 2007 From: henry.story at bblfish.net (Henry Story) Date: Tue, 29 May 2007 10:10:43 -0700 Subject: Global Relationships between bugs In-Reply-To: <465C31B8.6040106@mozilla.org> References: <465C31B8.6040106@mozilla.org> Message-ID: <4CFAFAAD-F58E-4133-9EB2-0AB2BD7581B4@bblfish.net> Hello, One problem with all bug tracking systems, is that they only allow you to state dependencies between bugs on one open source project. Problem is, that most open source project use libraries from other open source projects, which may themselves have bugs. So it can easily turn out that a bug in a project depends on a bug in another project. Since it is inconceivable that all open source projects use one big centralized bug database we need to do with the distributed system we have. Luckily this is easy, since we have URLs to name things on the web. So instead of identifying bugs with some primary key that is local to one database, we should be identifying them with URLs, and a good one to start with is the URLs of where they are published. So take the netbeans bug 51486 . It has URL http://www.netbeans.org/issues/show_bug.cgi?id=51486#bug So we should use that to describe it. Now if we want to say something about it, that it has a property of some sort we need to identify the property. Since we need this to work on a global scale, we should name the property in a way that is clear globally, and the only way to do this is to use a URI. So let's create one for saying that a bug depends on another bug http://baetle.googlecode.com/svn/ns/#depends_on Ok, so far so good, so we just need to get the URL of the bug it depends on, I'll invent one here http://issues.apache.org/bugzilla/show_bug.cgi?id=13099 Now we can write this out as a relation: . or if we use namespaces baetle:depends_on . Naming these relations is what the baetle prject is working on at http://baetle.googlecode.com/ It would be really great if we could get the involvement of the bugzilla community. Henry Home page: http://bblfish.net/ Sun Blog: http://blogs.sun.com/bblfish/ Foaf name: http://bblfish.net/people/henry/card#me On 29 May 2007, at 06:59, Gervase Markham wrote: > developers, > > In mozilla.dev.planning, people were lamenting that it's difficult > to correctly show that one bug was a regression caused by the > checkin for another. Neither "blocks" nor "depends on" are entirely > appropriate. > > A (proprietary) bug system I've used in the past has, instead of > just dependencies, the more general concept of relationships: you > give a bug number, and then say if it's blocking, blocks, > regression, duplicate or just related. (We wouldn't use > "duplicate", of course.) > > shaver rather liked this idea. Is this worth considering? We could > also use this mechanism to remember that a bug was a clone of > another, or perhaps that two bugs were for the same underlying > problem but on two different code branches. > > The UI could be simplified to show only those lines where there was > actually a bug in that relationship: > > Depends on: 12345, 34556 > Clones: 65433 > Branches: 75347 (1.3.1), 84346 (1.2.9) > > Add relationship: this bug [ blocks |V] bug(s): [ ] > > where the "blocks" dropdown could be "blocks", "depends on", "is a > branch version of", "is related to", "was caused by checkin from" etc. > > You could still plot dependency graphs using the "blocking" and > "blocks" relationships as we do now. > > What do you guys think? > > Gerv > - > To view or change your list settings, click here: > From justdave at bugzilla.org Tue May 29 17:21:27 2007 From: justdave at bugzilla.org (David Miller) Date: Tue, 29 May 2007 13:21:27 -0400 Subject: Relationships between bugs In-Reply-To: <465C4843.7060105@mozilla.org> References: <465C31B8.6040106@mozilla.org> <465C3B9E.5000308@gmail.com> <465C4843.7060105@mozilla.org> Message-ID: <465C6117.1030002@bugzilla.org> Gervase Markham wrote on 5/29/07 11:35 AM: > I don't think a custom field is the right solution. IMO, custom fields > are best when they are information that pertains only to a single bug, > and which has no special display requirements. "Customer name", that > sort of thing. Dependencies link bugs together, and have special display > requirements (dependencytree.cgi and dependencygraph.cgi). This makes me > think that a general system for relating bugs together should be part of > the core code. Well, you could change the blocks and depends to "interbug relationship" and allow custom relationship types. :) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From Guillaume.Rousse at inria.fr Tue May 29 19:10:54 2007 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Tue, 29 May 2007 21:10:54 +0200 Subject: Using Bugzilla to hide spam sites In-Reply-To: <46483D24.5010802@mozilla.org> References: <46483D24.5010802@mozilla.org> Message-ID: <465C7ABE.4050006@inria.fr> Gervase Markham a ?crit : > I'm not sure there's much we can do about this. The spammer obviously > took time to create an account - perhaps automatically, perhaps not. > Short of implementing Captchas for account signup, or refusing to > display HTML attachments as HTML, I can't see a counter. > > Thoughts? I've also requested a way to drop a whole bug report directly, not just invidual attachements one by one. See https://bugzilla.mozilla.org/show_bug.cgi?id=376637 -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62 From altlist at gmail.com Tue May 29 21:03:57 2007 From: altlist at gmail.com (Albert Ting) Date: Tue, 29 May 2007 14:03:57 -0700 Subject: how best to clean up data mining files after an updated custom workflow Message-ID: <34468ef80705291403k37892341j3b487513858be0a1@mail.gmail.com> I've been trying out the new custom workflow and it works really well. Good timing too, since we wanted to add some new status values by the end of June. In particular, we want to convert the REMIND/LATER close-status resolution values into a WAITING/PARKED open-status. While the new flow works, I'd like to clean up the data mining files (and perhaps the bugs_activity table) to reflect the new workflow. It sounds like I'll need to run a bunch of mysql commands to clean up the database and then regenerate the data mining files. But was wondering if there was a better solution? Thanks, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Wed May 30 00:41:05 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 29 May 2007 17:41:05 -0700 Subject: Relationships between bugs In-Reply-To: <465C31B8.6040106@mozilla.org> References: <465C31B8.6040106@mozilla.org> Message-ID: <20070530004257.69D8C11805C@help.trusthosting.net> On Tue, 29 May 2007 14:59:20 +0100 Gervase Markham wrote: > A (proprietary) bug system I've used in the past has, instead of just > dependencies, the more general concept of relationships: you give a > bug number, and then say if it's blocking, blocks, regression, > duplicate or just related. (We wouldn't use "duplicate", of course.) Yes: https://bugzilla.mozilla.org/show_bug.cgi?id=12286 I've discussed it for a while in dups of that bug as well, I think. (Or maybe I duped them to some other bug.) In the general scheme of how needed a feature is by how many organizations, it's not one of our top priorities, but of course if somebody writes it and somebody reviews it, then it could be useful. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Wed May 30 01:08:39 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 29 May 2007 18:08:39 -0700 Subject: Global Relationships between bugs In-Reply-To: <4CFAFAAD-F58E-4133-9EB2-0AB2BD7581B4@bblfish.net> References: <465C31B8.6040106@mozilla.org> <4CFAFAAD-F58E-4133-9EB2-0AB2BD7581B4@bblfish.net> Message-ID: <20070530011032.6B48411805A@help.trusthosting.net> On Tue, 29 May 2007 10:10:43 -0700 Henry Story wrote: > One problem with all bug tracking systems, is that they only allow > you to state dependencies between bugs on one open source project. > Problem is, that most open source project use libraries from other > open source projects, which may themselves have bugs. Yes, we have a bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=134294 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Wed May 30 01:10:29 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 29 May 2007 18:10:29 -0700 Subject: how best to clean up data mining files after an updated custom workflow In-Reply-To: <34468ef80705291403k37892341j3b487513858be0a1@mail.gmail.com> References: <34468ef80705291403k37892341j3b487513858be0a1@mail.gmail.com> Message-ID: <20070530011221.588A211805A@help.trusthosting.net> On Tue, 29 May 2007 14:03:57 -0700 "Albert Ting" wrote: > While the new flow works, I'd like to clean up the data mining files > (and perhaps the bugs_activity table) to reflect the new workflow. ./collectstats.pl --regenerate > It sounds like I'll need to run a bunch of mysql commands to clean up > the database and then regenerate the data mining files. But was > wondering if there was a better solution? Custom workflow isn't really "done" yet, upstream. So I'd wait until we're done with it. You could file a bug about this particular fact, if you want. However, I personally think that bugs_activity shouldn't be modified, as it's a historical record. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From altlist at gmail.com Wed May 30 01:22:52 2007 From: altlist at gmail.com (Albert Ting) Date: Tue, 29 May 2007 18:22:52 -0700 Subject: how best to clean up data mining files after an updated custom workflow In-Reply-To: <20070530011221.588A211805A@help.trusthosting.net> References: <34468ef80705291403k37892341j3b487513858be0a1@mail.gmail.com> <20070530011221.588A211805A@help.trusthosting.net> Message-ID: <34468ef80705291822w1d23873ek287a420e56f61a72@mail.gmail.com> On 5/29/07, Max Kanat-Alexander wrote: > On Tue, 29 May 2007 14:03:57 -0700 "Albert Ting" > wrote: > > While the new flow works, I'd like to clean up the data mining files > > (and perhaps the bugs_activity table) to reflect the new workflow. > > ./collectstats.pl --regenerate > Yes, but collectstats includes both the old and new status/resolution values. > > It sounds like I'll need to run a bunch of mysql commands to clean up > > the database and then regenerate the data mining files. But was > > wondering if there was a better solution? > > Custom workflow isn't really "done" yet, upstream. So I'd wait > until we're done with it. You could file a bug about this particular > fact, if you want. > > However, I personally think that bugs_activity shouldn't be > modified, as it's a historical record. I agree, I may just keep things as is for now. If the powers-to-be don't like it, I'll look into hacking up the database. From gerv at mozilla.org Wed May 30 14:39:30 2007 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 May 2007 15:39:30 +0100 Subject: Relationships between bugs In-Reply-To: <465C6117.1030002@bugzilla.org> References: <465C31B8.6040106@mozilla.org> <465C3B9E.5000308@gmail.com> <465C4843.7060105@mozilla.org> <465C6117.1030002@bugzilla.org> Message-ID: <465D8CA2.5020802@mozilla.org> David Miller wrote: > Well, you could change the blocks and depends to "interbug relationship" > and allow custom relationship types. :) Yes, that might work. Although you might want to hard-code some (like blocks/depends) so that dependency graphs still work. Gerv From henry.story at bblfish.net Wed May 30 23:30:42 2007 From: henry.story at bblfish.net (Henry Story) Date: Wed, 30 May 2007 16:30:42 -0700 Subject: Global Relationships between bugs In-Reply-To: <20070530011032.6B48411805A@help.trusthosting.net> References: <465C31B8.6040106@mozilla.org> <4CFAFAAD-F58E-4133-9EB2-0AB2BD7581B4@bblfish.net> <20070530011032.6B48411805A@help.trusthosting.net> Message-ID: <9742DA28-59FA-41D4-8B6C-79C95C106520@bblfish.net> Thanks for pointing this out. I hope I don't have to fill out another password registration to comment on that bug... The problem with how people are speaking about the issue there, is that they are restricting themselves to talking about referring to bugs within other bugzilla bug databases. It feels a little like an attempt at lock in, which is doomed to fail. Bugzilla, however good, is never going to own the whole bug market. Much better would be to work on interoperation between all the bug systems. That is what the baetle vocab is about. So I think really there is a great opportunity here to do something really big. I am in the bay area right now, btw. So if anyone is around here and would like me to give an overview of how this works, so as to make some brainstorming possible let me know. I have to fly back to Europe soonish. Henry On 29 May 2007, at 18:08, Max Kanat-Alexander wrote: > On Tue, 29 May 2007 10:10:43 -0700 Henry Story > wrote: >> One problem with all bug tracking systems, is that they only allow >> you to state dependencies between bugs on one open source project. >> Problem is, that most open source project use libraries from other >> open source projects, which may themselves have bugs. > > Yes, we have a bug for this: > > https://bugzilla.mozilla.org/show_bug.cgi?id=134294 > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla Services. And Everything Else, too. > - > To view or change your list settings, click here: > From mkanat at bugzilla.org Thu May 31 02:01:45 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 30 May 2007 19:01:45 -0700 Subject: Global Relationships between bugs In-Reply-To: <9742DA28-59FA-41D4-8B6C-79C95C106520@bblfish.net> References: <465C31B8.6040106@mozilla.org> <4CFAFAAD-F58E-4133-9EB2-0AB2BD7581B4@bblfish.net> <20070530011032.6B48411805A@help.trusthosting.net> <9742DA28-59FA-41D4-8B6C-79C95C106520@bblfish.net> Message-ID: <20070531020339.67BBE11805B@help.trusthosting.net> On Wed, 30 May 2007 16:30:42 -0700 Henry Story wrote: > Much better would be to > work on interoperation between all the bug systems. That is what the > baetle vocab is about. Yes...if you can get every other significant bug-tracker to agree to that...good luck. :-) > I am in the bay area right now, btw. So if anyone is around here and > would like me to give an overview of how this works, so as to make > some brainstorming possible let me know. How what works? Code that doesn't exist yet? Anyhow, I live in the Bay Area, if you want to email me directly. Although I'm pretty busy in the coming week or so. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.