From mkanat at bugzilla.org Thu Nov 1 20:59:02 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 1 Nov 2007 13:59:02 -0700 Subject: An Essay About Bugzilla Quality Message-ID: <20071101135902.5e5ac5f6@es-compy> One of my clients had a contractor who was looking at the lifecycle cost of various bug-trackers. They hadn't worked with open-source software much, and had some concerns about it. To help them out, I wrote a detailed essay about the quality of Bugzilla code and its process. I though it would be generally helpful for anyone evaluating Bugzilla, and so here it is, if you ever need or want to point somebody at it: http://wiki.mozilla.org/Bugzilla:About_Bugzilla_Quality Near the bottom, it also contains some good general arguments in favor of the open-source development process. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From dev-apps-bugzilla at lists.mozilla.org Fri Nov 2 09:09:46 2007 From: dev-apps-bugzilla at lists.mozilla.org (dev-apps-bugzilla at lists.mozilla.org) Date: Fri, 2 Nov 2007 02:09:46 -0700 (PDT) Subject: Fall's Lowest Prices Message-ID: <9031360.7099744201773.JavaMail.web@broadcast> _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From justdave at bugzilla.org Fri Nov 2 03:02:23 2007 From: justdave at bugzilla.org (David Miller) Date: Thu, 01 Nov 2007 23:02:23 -0400 Subject: [Fwd: Bugzilla and IEEE Software special issue on software development tools] Message-ID: <472A933F.5040100@bugzilla.org> This might be something interesting to get involved in. I know I'll never have time to do it though. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ -------------- next part -------------- An embedded message was scrubbed... From: "Helsen, Simon" Subject: Bugzilla and IEEE Software special issue on software development tools Date: Thu, 1 Nov 2007 18:02:34 +0100 Size: 9114 URL: From bugreport at peshkin.net Fri Nov 2 12:55:06 2007 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 02 Nov 2007 05:55:06 -0700 Subject: [Fwd: Bugzilla and IEEE Software special issue on software development tools] In-Reply-To: <472A933F.5040100@bugzilla.org> References: <472A933F.5040100@bugzilla.org> Message-ID: <472B1E2A.60700@peshkin.net> David Miller wrote: > This might be something interesting to get involved in. I know I'll > never have time to do it though. > > Call me cynical, but somehow, I suspect it will be an IBM/Rational advocacy issue. At a minimum, I doubt it would dare imply that OSS tools make more sense for most companies than those sold by the guest editors' companies. From kevin.benton at amd.com Fri Nov 2 18:24:25 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 2 Nov 2007 11:24:25 -0700 Subject: Bugzilla Contribution Process (was RE: New language discussion?) In-Reply-To: <20071031121149.64b43cf6@es-compy> References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> <47287143.5020201@mozilla.org> <20071031121149.64b43cf6@es-compy> Message-ID: > The only reason Bugzilla currently works that way is that > isactive isn't used. That's interesting. Why have those fields then? > > > field schemes [snip] > > I already have code that does this. It may even get into 3.2. This is one of the challenges of working with the open source community in general. With an in-house development team, we communicate to each other on projects we're working on and nobody does anything "behind the scenes" without communicating at least that it's being done to others working on the project. This is the first I've heard of anyone else developing field schemes. I haven't seen field schemes on a roadmap indicating that work was even being considered. > > For the purpose of searching, we've made some other > improvements such > > as adding a bug_values_cache table that stores a bug_id, and the > > values of many-to-many relationships for each bug (such as the CC > > list members by email and dependency relationships). > > See, funny, because we're actually re-writing things to > eliminate those. :- So are we for the purpose of general use, however, we need the denormalization to keep large volume queries operating relatively quickly. Our expectation is to use triggers to update the bug_values_cache table, though I know that doing it that way isn't compatible with some of the databases Bugzilla supports currently (like MySQL 4.1.x). The speed decrease on the update end is worth the dramatic speed increase on the search end. > > We're also adding a description column to every table that doesn't > > already have one for the purpose of improving the help system so it > > can describe a table's values. > > The help system was already improved to allow for adding help > to any page. For us, we'd have to do this in a localizable way. The challenge from an administrative standpoint is anytime someone has to touch a template in order to change help, that's seen as a code change rather than a configuration change. Maybe I'm out of date with what is happening with the help system, but it's my understanding at this point that changing help requires changing the template instead of data in the database. I hope I'm wrong. :-) > > [snip] There are also times when we > > feel we just can't wait for the community to review and approve what > > we're doing. > > And that's reasonable. That's one of the advantages of Open > Source code. It's both an advantage and a disadvantage depending on perspective. We really want to contribute, but there is a real cost of contributing, just like there's a cost to fork (loss of ability to easily incorporate community updates). > > There are other pieces that we've developed that we > > clearly want to see included, yet will take significant effort > > because someone has to syncronize that code with the current tip. > > [snip] > > In that case, I'd recommend hiring a contractor to help you out > with the process, somebody who's a core member of the Bugzilla team or > a proven Bugzilla contributor. You might think this is a subtle > self-advertisement, but it's not--there are many contractors, and I > really do think this is a great way to give back to the community and > also see your own goals realized. I don't know how well that will fly with management - spend money to pay a contractor to incorporate something we're giving away into the community version... Yes, I understand it has benefits, but I just don't know if I can sell it. It's a valid option to consider, however. The question I will have to be able to answer in order to sell it is can we justify the cost considering the cost of the fork versus remaining much more in-sync... > > It's an issue to explain that we're dealing with forward > > compatibility with Bugzilla. > > I'd be happy to explain this to anybody who wants to talk about > it. > > I suspect that your managers don't understand the advantages of > open source? That is, *somebody else*, who *doesn't work at your > company*, is *also working on the code*. You get the work of many > people for free. Max - I agree that we get "stuff" for free, but we also have to consider the value we need versus the value we may get based on a time line we have no way to drive. Yes, open source is a great way to go when that source meets basic needs. > The solid equation to look at, that any reasonable management > will accept, is how much code you're getting for free versus how much > work it takes you to synchronize with upstream. Given enough time, > upstream will always win, because there's more people working > on it and > we're adding far more new features than one person possibly could. Yes, as long as upstream is going in the same direction as the needs of the company, hence the reason for contributing back where appropriate or forking if required (not preferred). > > If there are things that this community can do to help improve > > responsiveness by helping corporate contributors what kind of things > > will help reviews get done faster (such as submitting full sets of > > test cases and selenium test code to go with the developed code), > > then I think you'll see more sponsored contributions coming. > > Unfortunately the problem isn't limited to corporate > contributions, or even large contributions. We simply need more > reviewers. I agree with you with one addition - more *active* reviewers. If I had more time, I'd be doing more reviews myself. When there's a feature I'm interested in, I'm very likely to review. I also do keep an eye on documentation reviews. > Even with more reviewers, patches must be of a reviewable size. > I personally can edit down a patch to reasonable size at 2-3 hours > maximum. (Usually it takes far less time.) If you don't have 2-3 hours > to edit a patch, then you probably won't have time to revise > the patch, > and as much as I'd like to be able to help, the solution to > that problem > just logically doesn't lie with the Bugzilla Project. I agree that having patches at a reviewable size is important to make reviews go quickly. From a purely business perspective, however, there are times when justifying the extra time to get that code accepted is difficult. I understand, yes it does have benefits when accepted that now the company doesn't have to maintain it any longer, however, at the same time, there are no guarantees that a) it will be accepted, and b) that the effort to make it acceptable is worth the risk to get it there. This is especially true for large changes. > I often don't read or respond to very long posts, but I read > and responded to this one because the contribution process to Bugzilla > is extremely important to me. I have already worked to make it > easier and easier for new contributors to become known and contribute > their work to the Bugzilla Project. If anybody has some reasonable > ideas what can be done to further ease that process without relaxing > our code quality standards, do please let me know, either here or by > personal email. Max - the work you've done to help Bugzilla move forward has been greatly appreciated, not just by us here at AMD, but I'm sure by others across many organizations. The same is also appreciated of you on Fedora. Open source would loose out if you didn't participate. Thanks :-) Kevin --- Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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 kevin.benton at amd.com Fri Nov 2 18:29:27 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 2 Nov 2007 11:29:27 -0700 Subject: New language discussion? In-Reply-To: References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> Message-ID: > Benton, Kevin wrote: > > We're (AMD) actively working on a radical shift in the way > that "custom" > > fields are being done by providing a field scheme model of > implementing > > "custom" fields. We prefer to call those "custom" fields "add-on" > > fields rather than custom. Once the code support them, > then they truly > > will be add-on fields. While we're doing field schemes that allow > > administrators to select what fields are available by product, we're > > also developing workflow schemes in the same methodology so > that each > > product can have its own workflow. There are many > different workflow > > needs within our company based on the type of work being done. Some > > processes have an extra documentation step, some have an extra > > incorporation step, and there are many others. Not all > products need > > the extra steps so workflow schemes will allow us to assign those > > workflows on a per-product basis. > > I think this is great work, and it's too bad it ends up behind closed > doors only because of the difficulty to integrate it. > > I think you would render a great service to everybody by > providing it as > a fork. > > fork is an ugly word, but the truth is you already have that > fork, and > in addition to being a fork, nobody can see it. So it would be a > positive move to make it a public fork instead of a private one. > > Then, there would be a chance that someone else does the ugly work > needed to integrate it, or at least that bugzilla gets some > of it's most > interesting/easy to integrate elements. Jean - rather than posting a fork, we plan to make certain patches available that will implement our customizations from a point in time of Bugzilla code. My purpose for posting as I did yesterday was to further highlight the frustation at least two large companies are experiencing with attempting to "give back" to the Bugzilla code base. I received private responses from members of another very large user of Bugzilla (who will remain anonymous) that they share the same frustrations we do - that there is risk in contributing back to Bugzilla in that it may cost more effort to contribute back than to stay forked. Please see the other thread related to this one for more info. :-) Kevin --- Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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 kevin.benton at amd.com Fri Nov 2 19:21:04 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 2 Nov 2007 12:21:04 -0700 Subject: Bugzilla/Eclipse question: Tasks Message-ID: Has anyone here successfuly made Eclipse Perl Integration make the task list show tasks for .tmpl files along with the .cgi, .pl, and .pm files? Kevin --- Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2675 bytes Desc: image001.gif URL: From kevin.benton at amd.com Fri Nov 2 19:25:40 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 2 Nov 2007 12:25:40 -0700 Subject: Bugzilla/Eclipse question: Tasks Message-ID: Has anyone here successfuly made Eclipse Perl Integration make the task list show tasks for .tmpl files along with the .cgi, .pl, and .pm files? Kevin --- Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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 mkanat at bugzilla.org Fri Nov 2 21:12:32 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 2 Nov 2007 14:12:32 -0700 Subject: Bugzilla Contribution Process (was RE: New language discussion?) In-Reply-To: References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> <47287143.5020201@mozilla.org> <20071031121149.64b43cf6@es-compy> Message-ID: <20071102141232.49928089@es-compy> On Fri, 2 Nov 2007 11:24:25 -0700 "Benton, Kevin" wrote: > That's interesting. Why have those fields then? When I originally wrote that patch, I was extremely new to Bugzilla development, and I thought, "Oh, I'll just make them used in a future patch." Long experience has now taught me that that doesn't work, but those are left over as part of that error. > his is the first > I've heard of anyone else developing field schemes. I haven't seen > field schemes on a roadmap indicating that work was even being > considered. It would be essentially implemented by: https://bugzilla.mozilla.org/show_bug.cgi?id=291433 I do understand the difficulty of locating what's going on sometimes. > So are we for the purpose of general use, however, we need the > denormalization to keep large volume queries operating relatively > quickly. I wonder if they could be done just as quickly in the way Yahoo does it, with UNIONed selects with simple WHERE clauses. > The challenge from an administrative standpoint is anytime someone has > to touch a template in order to change help, that's seen as a code > change rather than a configuration change. Maybe I'm out of date with > what is happening with the help system, but it's my understanding at > this point that changing help requires changing the template instead > of data in the database. I hope I'm wrong. :-) No, it requires changing a template. That's the only way to be localizeable, currently. > It's both an advantage and a disadvantage depending on perspective. > We really want to contribute, but there is a real cost of > contributing, just like there's a cost to fork (loss of ability to > easily incorporate community updates). Sure. That's the exchange for the advantage of getting code that other people have developed. > I don't know how well that will fly with management - spend money to > pay a contractor to incorporate something we're giving away into the > community version... Yes, I understand it has benefits, but I just > don't know if I can sell it. It's a valid option to consider, > however. The question I will have to be able to answer in order to > sell it is can we justify the cost considering the cost of the fork > versus remaining much more in-sync... Yeah, I think that's a good equation. I can tell you that other major corporations of a similar size to AMD have done it, and it's been definitely beneficial to them. They no longer have to maintain that code (we do it for them), which is a huge advantage as more and more versions of Bugzilla are released. > I agree with you with one addition - more *active* reviewers. If I > had more time, I'd be doing more reviews myself. When there's a > feature I'm interested in, I'm very likely to review. I also do keep > an eye on documentation reviews. That's good to hear, that you're keeping an eye on those things. :-) Yes, more active reviewers would be great. > Max - the work you've done to help Bugzilla move forward has been > greatly appreciated, not just by us here at AMD, but I'm sure by > others across many organizations. The same is also appreciated of > you on Fedora. Open source would loose out if you didn't > participate. Thanks :-) Wow, thank YOU. :-) I'm totally smiling. :-) I'm touched. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From kevin.benton at amd.com Fri Nov 2 22:07:16 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 2 Nov 2007 15:07:16 -0700 Subject: Bugzilla Contribution Process (was RE: New language discussion?) In-Reply-To: <20071102141232.49928089@es-compy> References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> <47287143.5020201@mozilla.org> <20071031121149.64b43cf6@es-compy> <20071102141232.49928089@es-compy> Message-ID: > When I originally wrote that patch, I was extremely new to > Bugzilla development, and I thought, "Oh, I'll just make them > used in a > future patch." Long experience has now taught me that that doesn't > work, but those are left over as part of that error. Cut that out... I've done that... :-) > It would be essentially implemented by: > > https://bugzilla.mozilla.org/show_bug.cgi?id=291433 Thanks. It would be helpful if a document explained how to find items like this so others like us would be likely to run across those features... Even if it was a pointer to a query that looked for "wishlist" keywords or something... > > So are we for the purpose of general use, however, we need the > > denormalization to keep large volume queries operating relatively > > quickly. > > I wonder if they could be done just as quickly in the way Yahoo > does it, with UNIONed selects with simple WHERE clauses. How would that work? Do tell! :-) The more we can get away from denormalization, the easier it becomes to maintain code. I'd be glad to have an off-line with you and post the results back to the group. I haven't used UNION much at all myself. I bet I'm not alone... > > The challenge from an administrative standpoint is anytime > someone has > > to touch a template in order to change help, that's seen as a code > > change rather than a configuration change. Maybe I'm out > of date with > > what is happening with the help system, but it's my understanding at > > this point that changing help requires changing the template instead > > of data in the database. I hope I'm wrong. :-) > > No, it requires changing a template. That's the only way to be > localizeable, currently. That's true when you care about localization. The challenge that goes with it is now you have two places where a list of items must be maintained. So - now, instead of maintaining the list of components (for example) in the component list, in this model, I would also have to maintain the template for my component descriptions. That's not a level of complexity I'm ready to support. > > I don't know how well that will fly with management - spend money to > > pay a contractor to incorporate something we're giving away into the > > community version... Yes, I understand it has benefits, but I just > > don't know if I can sell it. It's a valid option to consider, > > however. The question I will have to be able to answer in order to > > sell it is can we justify the cost considering the cost of the fork > > versus remaining much more in-sync... > > Yeah, I think that's a good equation. I can tell you that other > major corporations of a similar size to AMD have done it, and > it's been > definitely beneficial to them. They no longer have to maintain that > code (we do it for them), which is a huge advantage as more and more > versions of Bugzilla are released. That helps to know too. :-) Kevin --- Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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 ghendricks at novell.com Fri Nov 2 22:24:40 2007 From: ghendricks at novell.com (Gregary Hendricks) Date: Fri, 02 Nov 2007 16:24:40 -0600 Subject: Bugzilla/Eclipse question: Tasks In-Reply-To: <472B4F48020000D2000144B2@sinclair.provo.novell.com> References: <472B258E0200009B00018C60@sinclair.provo.novell.com> <472B4F48020000D2000144B2@sinclair.provo.novell.com> Message-ID: <472B4F48020000D2000144B2@sinclair.provo.novell.com> On Fri, 2007-11-02 at 12:25 -0700, Benton, Kevin wrote: > Has anyone here successfuly made Eclipse Perl Integration make the task > list show tasks for .tmpl files along with the .cgi, .pl, and .pm files? > Works for me with #TODO: Greg From dmarshal at yahoo-inc.com Fri Nov 2 23:06:22 2007 From: dmarshal at yahoo-inc.com (David Marshall) Date: Fri, 2 Nov 2007 16:06:22 -0700 Subject: Query Improvement (was Re: Bugzilla Contribution Process (was RE: New language discussion?)) In-Reply-To: References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> <47287143.5020201@mozilla.org> <20071031121149.64b43cf6@es-compy> <20071102141232.49928089@es-compy> Message-ID: <6A9A414E-FAC1-4BF8-95CD-E59A5E46F94C@yahoo-inc.com> On Nov 2, 2007, at 3:07 PM, Benton, Kevin wrote: >> > >>> So are we for the purpose of general use, however, we need the >>> denormalization to keep large volume queries operating relatively >>> quickly. >> >> I wonder if they could be done just as quickly in the way Yahoo >> does it, with UNIONed selects with simple WHERE clauses. > > How would that work? Do tell! :-) The more we can get away from > denormalization, the easier it becomes to maintain code. I'd be > glad to > have an off-line with you and post the results back to the group. I > haven't used UNION much at all myself. I bet I'm not alone... > The technique is pretty simple, but the implementation is slightly less so... The source of the idea is Yahoo!'s own Jeremy Zawodny (plus probably many other inventors of the same technique): http://www.oreilly.com/catalog/hpmysql/index.html Consider this statement: SELECT * FROM bugs WHERE bug_status IN ('NEW, 'ACCEPTED', 'REOPENED') AND (assigned_to = 53922 OR reporter = 53922) With the exception of very small tables, MySQL cannot use either the index on assigned_to or the index on reporter. For our database, with about 1.5M rows in table bugs, the query optimizer uses the index on bug_status index. Yuck! Long, slow, query. It takes 2.55 on my development database. If we are writing queries by hand, this query can be trivially improved to: SELECT * FROM bugs WHERE bug_status IN ('NEW', 'ACCEPTED', 'REOPENED') AND assigned_to = 53922 UNION SELECT * FROM bugs WHERE bug_status IN ('NEW', 'ACCEPTED', 'REOPENED') AND reporter = 53922 Same results, but it takes 0.03 seconds on my development database. Big win! To use this in Bugzilla, the trick is to know when to transform statements with ORs into statements with UNIONs and then how to do so. To do it, I modified Search.pm to create what I call a "predicate tree." It's a tree of ANDs or ORs. I then transform that tree into a list of equivalent trees, run the query for each resulting predicate, and then combine the results. I don't actually create statements with UNION in them, but the idea is the same. Unfortunately, there are a lot of traps in this approach. It's easy to transform so-so queries into really bad queries. We have a very simplistic heuristic for deciding when to transform a query or to just let it go. For us, the end result is that we add about 30 milliseconds to every query on average, but the "worst" queries finish in a few seconds rather than several minutes. Furthermore, the main problem that we are solving this way manifests itself really only when replicating to a shadow database. If a very slow query is processing when a replication statement shows up, the replication must wait for the slow query. Then, any new queries must wait for the replication to finish. This can lead to a horrible logjam. Summary: The largest Bugzilla database, particularly when replicated to a shadow database, can exhibit poor performance resulting from advanced searches. The archetypal slow query is searching for all bugs that have been assigned to, reported by, or CCed by a particular user. Yahoo! has worked around the biggest bottlenecks by transforming some of these slow queries into a series of faster queries. However, this is really just an extreme example of the overall scalability problems that pervade Bugzilla (at least up to 2.22.0). Many sections of code interact with the database in ways that become very expensive as the database grows large. (I don't intend that as a criticism of Bugzilla in any way; I can only hope that our code would perform as well if someone uses it on a database one hundred times larger than ours.) Caveat: If you are trying to squeeze more performance from your Bugzilla, there are probably other ways to do it. This approach is crafted for a very specific set of circumstances. What's Next: First, I need to generalize the "predicate tree" notion into a CPAN module. (I will be stuck in Virginia and Pittsburgh in December/ January, so I am hopeful that this will happen no later than that time.) Second, we need to get our Bugzilla a little bit closer to current Bugzilla so that we can make meaningful patches. Then we can start to roll out our changes to Search.pm. Because most Bugzilla databases are pretty small, it's probably not going to have any noticeable effect on the performance of anyone's Bugzilla, unless you have at least 500K rows in your bugs table. Note: If you *do* have 500K rows in your bugs table and would like to discuss previewing some of our changes, please contact me directly. From mkanat at bugzilla.org Fri Nov 2 23:20:26 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 2 Nov 2007 16:20:26 -0700 Subject: Query Improvement (was Re: Bugzilla Contribution Process (was RE: New language discussion?)) In-Reply-To: <6A9A414E-FAC1-4BF8-95CD-E59A5E46F94C@yahoo-inc.com> References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> <47287143.5020201@mozilla.org> <20071031121149.64b43cf6@es-compy> <20071102141232.49928089@es-compy> <6A9A414E-FAC1-4BF8-95CD-E59A5E46F94C@yahoo-inc.com> Message-ID: <20071102162026.6cb9ad6e@es-compy> On Fri, 2 Nov 2007 16:06:22 -0700 David Marshall wrote: > Furthermore, the main problem that we are solving this way manifests > itself really only when replicating to a shadow database. If a very > slow query is processing when a replication statement shows up, the > replication must wait for the slow query. Then, any new queries > must wait for the replication to finish. This can lead to a horrible > logjam. This can probably be solved in 3.2 code by using transactions and allowing searches to do READ UNCOMMITTED transactions. Locks will be eliminated in 3.2 (I hope!) so there shouldn't be any more blocking. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From knocte at NO-SPAM-PLEASE-gmail.com Sat Nov 3 15:12:12 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses=22?=) Date: Sat, 03 Nov 2007 16:12:12 +0100 Subject: "Bug" word to be replaced? Message-ID: One thing that I've come out while reading the recent thread called "Re: Bugzilla Contribution Process (was RE: New language discussion?)" is a feature request that I bet would be quite interesting and much voted from a corporate point of view: capability of renaming the main word used for Bugzilla for "bug", in order to allow changing it to things like "issue", "ticket" or "problem". I haven't filed this RFE yet because I think that it must exist on BMO, but it's difficult to find because of no easy way of naming it. Anyone that could point me to it? This feature would be necessary in my case because when we use Bugzilla we tend to call all tickets as "bugs", and some are just new features, which is confusing. I know that there has been some discussion in the past about using Bugzilla as a ticket/task workflow, instead of (or besides) a bug reporting tool, but this is not what am requesting. I refer to be able to change all the occurrences of word "bug" to another customised one. Thanks, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Sat Nov 3 15:24:53 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 3 Nov 2007 08:24:53 -0700 Subject: "Bug" word to be replaced? In-Reply-To: References: Message-ID: <20071103082453.78d3736d@es-compy> On Sat, 03 Nov 2007 16:12:12 +0100 "Andr?s G. Aragoneses" wrote: > capability > of renaming the main word used for Bugzilla for "bug", in order to > allow changing it to things like "issue", "ticket" or "problem". This has already been possible for years. See template/en/default/global/variables.none.tmpl -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From knocte at NO-SPAM-PLEASE-gmail.com Sat Nov 3 15:30:20 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Sat, 03 Nov 2007 16:30:20 +0100 Subject: "Bug" word to be replaced? In-Reply-To: References: Message-ID: Max Kanat-Alexander escribi?: > On Sat, 03 Nov 2007 16:12:12 +0100 "Andr?s G. Aragoneses" > wrote: >> capability >> of renaming the main word used for Bugzilla for "bug", in order to >> allow changing it to things like "issue", "ticket" or "problem". > > This has already been possible for years. See > template/en/default/global/variables.none.tmpl Thanks! Mmm, but what about changing it on Bugzilla preferences instead of in a template? Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From knocte at NO-SPAM-PLEASE-gmail.com Sat Nov 3 15:41:53 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Sat, 03 Nov 2007 16:41:53 +0100 Subject: "Bug" word to be replaced? In-Reply-To: References: Message-ID: Max Kanat-Alexander escribi?: > On Sat, 03 Nov 2007 16:12:12 +0100 "Andr?s G. Aragoneses" > wrote: >> capability >> of renaming the main word used for Bugzilla for "bug", in order to >> allow changing it to things like "issue", "ticket" or "problem". > > This has already been possible for years. See > template/en/default/global/variables.none.tmpl BTW: this does not change the behaviour of Bugzilla when placing links as you write "bug XXX". Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Sat Nov 3 16:00:32 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 3 Nov 2007 09:00:32 -0700 Subject: "Bug" word to be replaced? In-Reply-To: References: Message-ID: <20071103090032.357a4e1f@es-compy> On Sat, 03 Nov 2007 16:41:53 +0100 "Andr?s G. Aragoneses" wrote: > BTW: this does not change the behaviour of Bugzilla when placing > links as you write "bug XXX". Yes it does. At least, in modern versions. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From knocte at NO-SPAM-PLEASE-gmail.com Sat Nov 3 16:02:40 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Sat, 03 Nov 2007 17:02:40 +0100 Subject: "Bug" word to be replaced? In-Reply-To: References: Message-ID: <8sydna2oJNMKBrHanZ2dnUVZ_s7inZ2d@mozilla.org> Max Kanat-Alexander escribi?: > On Sat, 03 Nov 2007 16:41:53 +0100 "Andr?s G. Aragoneses" > wrote: >> BTW: this does not change the behaviour of Bugzilla when placing >> links as you write "bug XXX". > > Yes it does. At least, in modern versions. Hugh, I'm using 2.22.x yet. When did this feature enter? Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Sat Nov 3 16:07:51 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 3 Nov 2007 09:07:51 -0700 Subject: "Bug" word to be replaced? In-Reply-To: <8sydna2oJNMKBrHanZ2dnUVZ_s7inZ2d@mozilla.org> References: <8sydna2oJNMKBrHanZ2dnUVZ_s7inZ2d@mozilla.org> Message-ID: <20071103090751.58900a71@es-compy> On Sat, 03 Nov 2007 17:02:40 +0100 "Andr?s G. Aragoneses" wrote: > Hugh, I'm using 2.22.x yet. When did this feature enter? 3.0. IRC would probably be a better place to discuss this. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From knocte at NO-SPAM-PLEASE-gmail.com Sat Nov 3 16:09:23 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Sat, 03 Nov 2007 17:09:23 +0100 Subject: "Bug" word to be replaced? In-Reply-To: References: <8sydna2oJNMKBrHanZ2dnUVZ_s7inZ2d@mozilla.org> Message-ID: Max Kanat-Alexander escribi?: > On Sat, 03 Nov 2007 17:02:40 +0100 "Andr?s G. Aragoneses" > wrote: >> Hugh, I'm using 2.22.x yet. When did this feature enter? > > 3.0. > > IRC would probably be a better place to discuss this. Ok, sorry. Anyway, if this type of features were migrated to general preferences (instead of template editing), they would be much less missed. I will open a bug for that. Thanks very much. Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Sat Nov 3 16:13:12 2007 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sat, 03 Nov 2007 17:13:12 +0100 Subject: "Bug" word to be replaced? In-Reply-To: References: <8sydna2oJNMKBrHanZ2dnUVZ_s7inZ2d@mozilla.org> Message-ID: <472C9E18.9080508@gmail.com> > Ok, sorry. Anyway, if this type of features were migrated to general > preferences (instead of template editing), they would be much less > missed. I will open a bug for that. No, we won't implement this. This is a template thing (especially due to l10n). LpSolit From vladd at bugzilla.org Sat Nov 3 22:53:50 2007 From: vladd at bugzilla.org (Vlad Dascalu) Date: Sat, 3 Nov 2007 23:53:50 +0100 Subject: "Bug" word to be replaced? In-Reply-To: References: Message-ID: You simply need to change the word at the bottom of: http://mxr.mozilla.org/mozilla/source/webtools/bugzilla/template/en/default/global/variables.none.tmpl On 11/3/07, "Andr?s G. Aragoneses" wrote: > One thing that I've come out while reading the recent thread called "Re: > Bugzilla Contribution Process (was RE: New language discussion?)" is a > feature request that I bet would be quite interesting and much voted > from a corporate point of view: capability of renaming the main word > used for Bugzilla for "bug", in order to allow changing it to things > like "issue", "ticket" or "problem". > > I haven't filed this RFE yet because I think that it must exist on BMO, > but it's difficult to find because of no easy way of naming it. Anyone > that could point me to it? > > This feature would be necessary in my case because when we use Bugzilla > we tend to call all tickets as "bugs", and some are just new features, > which is confusing. > > I know that there has been some discussion in the past about using > Bugzilla as a ticket/task workflow, instead of (or besides) a bug > reporting tool, but this is not what am requesting. I refer to be able > to change all the occurrences of word "bug" to another customised one. > > Thanks, > > Andr?s [ knocte ] > > -- > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > > From knocte at NO-SPAM-PLEASE-gmail.com Sun Nov 4 13:04:41 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Sun, 04 Nov 2007 14:04:41 +0100 Subject: "Bug" word to be replaced? In-Reply-To: References: <8sydna2oJNMKBrHanZ2dnUVZ_s7inZ2d@mozilla.org> Message-ID: Fr?d?ric Buclin escribi?: >> Ok, sorry. Anyway, if this type of features were migrated to general >> preferences (instead of template editing), they would be much less >> missed. I will open a bug for that. > > No, we won't implement this. This is a template thing (especially due to > l10n). But maybe it's interesting to show it as a bugzilla preference, informing the administrator the downside that he won't get the word translated. BTW: I have changed mine, and I keep getting the word "Bug" in e-mails. Is this a bug fixed in recent versions? Sorry, don't have an IRC client available :) Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Sun Nov 4 19:16:49 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 4 Nov 2007 11:16:49 -0800 Subject: "Bug" word to be replaced? In-Reply-To: References: <8sydna2oJNMKBrHanZ2dnUVZ_s7inZ2d@mozilla.org> Message-ID: <20071104111649.7860892b@es-compy> On Sun, 04 Nov 2007 14:04:41 +0100 "Andr?s G. Aragoneses" wrote: > BTW: I have changed mine, and I keep getting the word "Bug" in > e-mails. Is this a bug fixed in recent versions? Yeah, it should be. > Sorry, don't have an IRC client available :) http://landfill.bugzilla.org/irc/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From jmdesp at alussinan.org Mon Nov 5 19:00:28 2007 From: jmdesp at alussinan.org (Jean-Marc Desperrier) Date: Mon, 05 Nov 2007 20:00:28 +0100 Subject: New language discussion? In-Reply-To: References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> Message-ID: Benton, Kevin wrote: > Jean - rather than posting a fork, we plan to make certain patches > available that will implement our customizations from a point in time of > Bugzilla code. You know, either you do it once and never update it, or a fork will be more convenient for everyone. It would take you almost no time and no ressource to put it Google code, for example. But I hope you can wrok out a way of contributing it back to the main code of course. BTW: it seem if I post on the newsgroup and you answer on the mailing-list, your answer ends up as two post on the newsgroup (I don't know for the mailing-list) _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From knocte at NO-SPAM-PLEASE-gmail.com Wed Nov 7 12:20:37 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses=22?=) Date: Wed, 07 Nov 2007 13:20:37 +0100 Subject: PerlNET? (was: Re: New language discussion?) Message-ID: Jean-Marc Desperrier escribi?: > Andr?s G. Aragoneses wrote: >> Hey, but I proposed Mono. With that, we could write things in >> IronPython, IronRuby... and have good stuff from contributors like C#, >> all languages interacting together. > > As well as javascript ( http://www.mono-project.com/JScript ) and perl ! > (though PerlNet). Thinking about this answer from Jean-Marc, I'm just wondering... why not switching whole Bugzilla to PerlNet in order to allow full CLR-interoperability, and then start accepting components/libraries from other languages (and/or migrating parts from PerlNET to other language, if interesting). I guess that a migration to a new version of a language would be much less time-consuming than a whole re-write. Is PerlNET mature? Does it have an official release date? Will it overlap with Perl v.6? Excuse my ignorance about Perl please. Just my 2c. Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Wed Nov 7 22:01:30 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 7 Nov 2007 14:01:30 -0800 Subject: PerlNET? (was: Re: New language discussion?) In-Reply-To: References: Message-ID: <20071107140130.3c083768@es-compy> On Wed, 07 Nov 2007 13:20:37 +0100 "Andr?s G. Aragoneses" wrote: > Thinking about this answer from Jean-Marc, I'm just wondering... why > not switching whole Bugzilla to PerlNet in order to allow full > CLR-interoperability, and then start accepting components/libraries > from other languages (and/or migrating parts from PerlNET to other > language, if interesting). I guess that a migration to a new version > of a language would be much less time-consuming than a whole re-write. > > Is PerlNET mature? Does it have an official release date? Will it > overlap with Perl v.6? > > Excuse my ignorance about Perl please. Just my 2c. I'm pretty sure PerlNET is not mature, and that we'd have all sorts of troubles with it, but I think your suggestion is an excellent one from a technical standpoint otherwise. Not that we're going to do it, just that it is indeed a good solution to what would be a difficult problem. Perl 6 should actually be implementable as a native mono language, though Larry Wall says it will be tricky. PerlNET for Perl 5 is actually just running the Perl interpreter with some Perl modules that allow bindings back into .NET. The other option is to use Facebook's Thrift. I know that some people were thinking of writing Perl bindings for it, which would allow us to use it for a slow transition. If you're really interested in this re-write thing, I'd be happy to help you with it in terms of advice, but not currently in terms of development. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From ppetrocelli at it-sistemas.com Thu Nov 8 16:17:23 2007 From: ppetrocelli at it-sistemas.com (McPetro) Date: Thu, 08 Nov 2007 13:17:23 -0300 Subject: =?ISO-8859-1?Q?Quienes_estan_haciendo_las_traducciones_?= =?ISO-8859-1?Q?al_espa=F1ol_=3F=3F=3F=3F?= Message-ID: thanks im using bugzilla 3.02 _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From knocte at NO-SPAM-PLEASE-gmail.com Thu Nov 8 18:30:52 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Thu, 08 Nov 2007 19:30:52 +0100 Subject: PerlNET? (was: Re: New language discussion?) In-Reply-To: References: Message-ID: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> Max Kanat-Alexander escribi?: > On Wed, 07 Nov 2007 13:20:37 +0100 "Andr?s G. Aragoneses" > wrote: >> Thinking about this answer from Jean-Marc, I'm just wondering... why >> not switching whole Bugzilla to PerlNet in order to allow full >> CLR-interoperability, and then start accepting components/libraries >> from other languages (and/or migrating parts from PerlNET to other >> language, if interesting). I guess that a migration to a new version >> of a language would be much less time-consuming than a whole re-write. >> >> Is PerlNET mature? Does it have an official release date? Will it >> overlap with Perl v.6? >> >> Excuse my ignorance about Perl please. Just my 2c. > > I'm pretty sure PerlNET is not mature, and that we'd have all > sorts of troubles with it, but I think your suggestion is an excellent > one from a technical standpoint otherwise. Not that we're going to do > it, just that it is indeed a good solution to what would be a difficult > problem. > > Perl 6 should actually be implementable as a native mono > language, though Larry Wall says it will be tricky. PerlNET for Perl 5 > is actually just running the Perl interpreter with some Perl modules > that allow bindings back into .NET. > > The other option is to use Facebook's Thrift. I know that some > people were thinking of writing Perl bindings for it, which would allow > us to use it for a slow transition. > > If you're really interested in this re-write thing, I'd be > happy to help you with it in terms of advice, but not currently in > terms of development. Thanks for your comments! Unfortunately I'm only interested in this because it would allow me (and my team) to become a contributor (and I guess that I'm not alone, many people would start contributing when many languages are available to do it). However I surely won't be available for helping in this port because I have minimal experience in Perl. Anyway, if I could dedicate my time to this, I wouldn't spend any effort until all bugzilla community had agreed by consensus about it, or otherwise I guess the effort would be useless. Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From spamsux at forgetit.org Thu Nov 8 18:34:07 2007 From: spamsux at forgetit.org (Steve Wendt) Date: Thu, 08 Nov 2007 10:34:07 -0800 Subject: PerlNET? (was: Re: New language discussion?) In-Reply-To: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> References: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> Message-ID: On 11/8/2007 10:30 AM, Andr?s G. Aragoneses wrote: > many people would start contributing when many languages are available It seems to me that getting contributions in several languages would be completely unmanageable. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From bugreport at peshkin.net Thu Nov 8 18:43:34 2007 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 8 Nov 2007 10:43:34 -0800 (PST) Subject: PerlNET? (was: Re: New language discussion?) In-Reply-To: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> References: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> Message-ID: <49499.206.169.229.170.1194547414.squirrel@peshkin.net> > > Unfortunately I'm only interested in this because it would allow me (and > my team) to become a contributor (and I guess that I'm not alone, many > people would start contributing when many languages are available to do > it). However I surely won't be available for helping in this port > because I have minimal experience in Perl. > Actually, when I stared contributing to Bugzilla, I was learning Perl and learning Bugzilla at the same time. It took a lot more doing to genuinely understand Bugzilla than it did to learn Perl. I suspect others had a similar experience. From knocte at NO-SPAM-PLEASE-gmail.com Thu Nov 8 18:52:09 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Thu, 08 Nov 2007 19:52:09 +0100 Subject: PerlNET? (was: Re: New language discussion?) In-Reply-To: References: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> Message-ID: <47335AD9.6090406@NO-SPAM-PLEASE-gmail.com> Steve Wendt escribi?: >> many people would start contributing when many languages are available > > It seems to me that getting contributions in several languages would be > completely unmanageable. I agree with you but not completely. Maybe the optimal way would be to: a) Consider only ONE language (for core Bugzilla bits) which could be the better considered one by the most important developers of Bugzilla (regarding this item, CLR interoperability would be just an instrument to allow progressive re-write from PerlNET to this language). b) Allow CLR compatibility at an add-in/extension level, in order to allow people design modules that could not be part of the official release (identical as Firefox has succeeded this way, but allowing any language). c) Besides the "best language" in term (a), allow an additional subset of languages (decided by community) for less important parts or contributed modules that would be interesting to integrate in the main release. The idea is to leverage the advantage of having much more potential contributions against the hypothetical situation in which a multi-language product could suppose unmaintainable or spaghetti code. Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From knocte at NO-SPAM-PLEASE-gmail.com Thu Nov 8 18:56:39 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses=22?=) Date: Thu, 08 Nov 2007 19:56:39 +0100 Subject: PerlNET? (was: Re: New language discussion?) In-Reply-To: References: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> Message-ID: <47335BE7.5090509@NO-SPAM-PLEASE-gmail.com> Joel Peshkin escribi?: >> Unfortunately I'm only interested in this because it would allow me (and >> my team) to become a contributor (and I guess that I'm not alone, many >> people would start contributing when many languages are available to do >> it). However I surely won't be available for helping in this port >> because I have minimal experience in Perl. >> > > Actually, when I stared contributing to Bugzilla, I was learning Perl and > learning Bugzilla at the same time. It took a lot more doing to genuinely > understand Bugzilla than it did to learn Perl. I suspect others had a > similar experience. Actually, I have worked with Perl for more than one year, but I guess I have the same feeling as the developer that started the "new language" discussion. IMHO Perl is improductive and unmaintainable in many ways (however I don't know the new v.6), and many of these kind of appreciations have been written here [1]. Besides, my team could only contribute in C# or Java. Regards, Andr?s [ knocte ] -- [1] http://wiki.mozilla.org/Bugzilla:Languages _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From knocte at NO-SPAM-PLEASE-gmail.com Thu Nov 8 19:04:48 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Thu, 08 Nov 2007 20:04:48 +0100 Subject: PerlNET? (was: Re: New language discussion?) In-Reply-To: <47335AD9.6090406@NO-SPAM-PLEASE-gmail.com> References: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> <47335AD9.6090406@NO-SPAM-PLEASE-gmail.com> Message-ID: <47335DD0.8060107@NO-SPAM-PLEASE-gmail.com> Andr?s G. Aragoneses escribi?: > Steve Wendt escribi?: >>> many people would start contributing when many languages are available >> >> It seems to me that getting contributions in several languages would >> be completely unmanageable. > > I agree with you but not completely. Maybe the optimal way would be to: > > a) Consider only ONE language (for core Bugzilla bits) which could be > the better considered one by the most important developers of Bugzilla > (regarding this item, CLR interoperability would be just an instrument > to allow progressive re-write from PerlNET to this language). > b) Allow CLR compatibility at an add-in/extension level, in order to > allow people design modules that could not be part of the official > release (identical as Firefox has succeeded this way, but allowing any > language). > c) Besides the "best language" in term (a), allow an additional subset > of languages (decided by community) for less important parts or > contributed modules that would be interesting to integrate in the main > release. > > The idea is to leverage the advantage of having much more potential > contributions against the hypothetical situation in which a > multi-language product could suppose unmaintainable or spaghetti code. Furthermore, right now there are many tools that allow decompiling from IL code or converting between .NET languages so rewriting could be almost automatic. Think about the situation in which someone created an interesting module in VB.NET, but VB.NET wasn't in the subset of "official Bugzilla" languages; it could be converted to C# and be included in the main release. Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Thu Nov 8 20:06:18 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 8 Nov 2007 12:06:18 -0800 Subject: PerlNET? (was: Re: New language discussion?) In-Reply-To: References: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> Message-ID: <20071108120618.67ae7847@es-compy> On Thu, 08 Nov 2007 10:34:07 -0800 Steve Wendt wrote: > On 11/8/2007 10:30 AM, Andr?s G. Aragoneses wrote: > > > many people would start contributing when many languages are > > available > > It seems to me that getting contributions in several languages would > be completely unmanageable. Yes, it would have to be only in two languages--Perl and whatever we transitioned to. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 8 20:08:33 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 8 Nov 2007 12:08:33 -0800 Subject: PerlNET? (was: Re: New language discussion?) In-Reply-To: <49499.206.169.229.170.1194547414.squirrel@peshkin.net> References: <9t6dnY4ySNRPyK7anZ2dnUVZ_gqdnZ2d@mozilla.org> <49499.206.169.229.170.1194547414.squirrel@peshkin.net> Message-ID: <20071108120833.2f82dc76@es-compy> On Thu, 8 Nov 2007 10:43:34 -0800 (PST) "Joel Peshkin" wrote: > I suspect others had a similar experience. Yes, I certainly did. :-) Particularly with how Bugzilla was when I started! (And you started even earlier than me!) There were some things about Perl that were pretty tricky, though. To this day I still watch for fundamental syntax errors (ones that "work anyway") even in patches from advanced contributors. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From jmdesp at alussinan.org Fri Nov 9 17:59:03 2007 From: jmdesp at alussinan.org (Jean-Marc Desperrier) Date: Fri, 09 Nov 2007 18:59:03 +0100 Subject: Is the change in the word wrap rule possible? In-Reply-To: References: <20071106090030.97006.qmail@web2904.mail.tnz.yahoo.co.jp> Message-ID: Jean-Marc Desperrier wrote: > Marc Schumann wrote: >> 2007/11/6, Komiyama Yukie : >>> --- Present result ---- >>> XXXXXXissue statusXXXXXXXXX[omission]XXXXXX >>> --- Wanted result ---- >>> XXXXXXissue statusXXXXXXXXX[omission]XX >>> XXXX Should have been --- Input sentence ---- XXXXXXissue statusXXXXXXXXX[omission]XXXXXX --- Present result ---- XXXXXXissue statusXXXXXXXXX[omission]XXXXXX --- Wanted result ---- XXXXXXissue statusXXXXXXXXX[omission]XX XXXX _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From jmdesp at alussinan.org Fri Nov 9 17:56:43 2007 From: jmdesp at alussinan.org (Jean-Marc Desperrier) Date: Fri, 09 Nov 2007 18:56:43 +0100 Subject: Is the change in the word wrap rule possible? In-Reply-To: References: <20071106090030.97006.qmail@web2904.mail.tnz.yahoo.co.jp> Message-ID: Marc Schumann wrote: > 2007/11/6, Komiyama Yukie : >> Users of my Bugzilla are using English and Japanese. >> X : Character of Japanese >> --- Present result ---- >> XXXXXXissue >> statusXXXXXXXXX[omission]XXXXXX >> --- Wanted result ---- >> XXXXXXissue statusXXXXXXXXX[omission]XX >> XXXX >> In version 3.0(utf-8), is the change in the word wrap rule possible? > [...] >> Could you teach the method of changing the rule of word wrap? >> I have not edited *.pm file. >> And, I was not able to find the wrap() function* where being described. > > you probably need to look at function wrap_comment in Bugzilla/Util.pm. According to Yukie's description, it seems like this wrap_comment function has a serious i18n problem . When I look in lxr, everything's done using Text::Wrap : http://lxr.mozilla.org/bugzilla/source/Bugzilla/Util.pm#299 And when I look at Text::Wrap in CPAN, it looks like it might known nothing about i18n : http://search.cpan.org/~muir/Text-Tabs+Wrap-2006.1117/lib/Text/Wrap.pm "It is possible to control which characters terminate words by modifying $Text::Wrap::break. [...] The default is simply '\s'; that is, words are terminated by spaces." I think the solution is to replace it with Unicode::Wrap : http://search.cpan.org/~nesting/Unicode-Wrap-0.03/Wrap.pm This module implements UAX#14: Line Breaking Properties. Unfortunately, Unicode::Wrap doesn't seem to be a direct replacement, also it might have performance problems "This module can be slow. It's a pure-Perl implementation that goes through an expensive classification process per character." And it won't do Thai correctly ;-) _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Fri Nov 9 20:12:13 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 9 Nov 2007 12:12:13 -0800 Subject: Is the change in the word wrap rule possible? In-Reply-To: References: <20071106090030.97006.qmail@web2904.mail.tnz.yahoo.co.jp> Message-ID: <20071109121213.71ff43e6@es-compy> On Fri, 09 Nov 2007 18:56:43 +0100 Jean-Marc Desperrier wrote: > According to Yukie's description, it seems like this wrap_comment > function has a serious i18n problem. Yes. See: https://bugzilla.mozilla.org/show_bug.cgi?id=388723 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From weizhan2008 at 126.com Mon Nov 12 02:41:06 2007 From: weizhan2008 at 126.com (James Will) Date: Mon, 12 Nov 2007 10:41:06 +0800 Subject: how can i use "filter html"? Message-ID: I'm a green hand, can someone give me some suggestion? _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From christian.masopust at siemens.com Wed Nov 14 11:47:05 2007 From: christian.masopust at siemens.com (Masopust, Christian) Date: Wed, 14 Nov 2007 12:47:05 +0100 Subject: Multiple Bugzilla databases with a single installation AND each with it's own skin... Message-ID: <60721B67EAF0994EAFFB561767B700140125DBB1@nets13ha.ww300.siemens.net> Sorry to again bother the developers, but as i didn't get any answer from the support-list... maybe you can help. what i would like is to have multiple instances of bugzilla within one code-base and each of them having it's own skin by default (skin not user-related but project-related). would this be possible (without changing the code)? how?? thanks a lot, christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Wed Nov 14 19:49:42 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 14 Nov 2007 11:49:42 -0800 Subject: Multiple Bugzilla databases with a single installation AND each with it's own skin... In-Reply-To: <60721B67EAF0994EAFFB561767B700140125DBB1@nets13ha.ww300.siemens.net> References: <60721B67EAF0994EAFFB561767B700140125DBB1@nets13ha.ww300.siemens.net> Message-ID: <20071114114942.66363cb2@es-compy> On Wed, 14 Nov 2007 12:47:05 +0100 "Masopust, Christian" wrote: > Sorry to again bother the developers, but as i didn't get any answer > from the support-list... Hi Christian. Unfortunately, this isn't a development question. If you don't get any answer on the support list, the next thing you should try is IRC: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From kevin.benton at amd.com Thu Nov 15 17:45:48 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 15 Nov 2007 09:45:48 -0800 Subject: Bug Field Scheme Templates Message-ID: In order to ask my question, I need to give a little background: AMD is in the process of coding "bug field schemes" - the ability to make a list of fields that are available by product. An installation will have the ability to have several field schemes, each of which can be used by multiple products allowing product owners to determine the set of fields that make the most sense for that product. To facilitate that, we're looking into how we extend the templating system so that it knows where to find the appropriate template for the given product. The question is, what is the best way to add field schemes into the template directory structure? We're considering the following: template/en/default/bug/fs_/... or template/en/field_scheme/fs_/... Considering that this code may get contributed back to the community (notwithstanding what others may already be doing), what is most likely to be accepted at this point? I ask because we are committed to completing our own field scheme implementation before month end and I'd like it to be as close to "acceptable" to the community at large as possible. Kevin Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.benton at amd.com Thu Nov 15 19:28:07 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 15 Nov 2007 11:28:07 -0800 Subject: Bug Field Scheme Templates In-Reply-To: References: Message-ID: Hi Michael, I don't know why you're suggesting that. Can you explain? Please note that this is not a skinning issue, rather a decision to display or not display fields entirely based on the product-selected field scheme. For example, a field scheme may show "Version" while another may not. Kevin Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. > -----Original Message----- > From: Tosh, Michael J [mailto:michael.j.tosh at lmco.com] > Sent: Thursday, November 15, 2007 11:00 AM > To: Benton, Kevin; developers at bugzilla.org > Subject: RE: Bug Field Scheme Templates > > While I can't speak for the developers, I'd like to suggest that you > look at it like a full template skin. > > template//skins// > > Where if the product uses a skin, attempt to load the skin's template > first, and if it isn't there, use the > template//default/ instead. > > > > -----Original Message----- > From: dev-apps-bugzilla-bounces at lists.mozilla.org > [mailto:dev-apps-bugzilla-bounces at lists.mozilla.org] On Behalf Of > Benton, Kevin > Sent: Thursday, November 15, 2007 12:46 PM > To: developers at bugzilla.org > Subject: Bug Field Scheme Templates > > In order to ask my question, I need to give a little background: > > > > AMD is in the process of coding "bug field schemes" - the ability to > make a list of fields that are available by product. An installation > will have the ability to have several field schemes, each of which can > be used by multiple products allowing product owners to determine the > set of fields that make the most sense for that product. To facilitate > that, we're looking into how we extend the templating system so that it > knows where to find the appropriate template for the given product. > > > > The question is, what is the best way to add field schemes into the > template directory structure? We're considering the following: > > > > template/en/default/bug/fs_/... > > > > or > > > > template/en/field_scheme/fs_/... > > > > Considering that this code may get contributed back to the community > (notwithstanding what others may already be doing), what is most likely > to be accepted at this point? I ask because we are committed to > completing our own field scheme implementation before month end and I'd > like it to be as close to "acceptable" to the community at large as > possible. > > > > Kevin > > > Kevin Benton > MySQL DBA #5739 > Senior Software Developer > CAD Global Infrastructure Flow Services > Advanced Micro Devices > 2950 E Harmony Rd > Fort Collins, CO 80528 > > > > 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. > > > > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > From kevin.benton at amd.com Thu Nov 15 19:35:30 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 15 Nov 2007 11:35:30 -0800 Subject: Bug Field Scheme Templates In-Reply-To: References: Message-ID: > Hi Michael, > > I don't know why you're suggesting that. Can you explain? Please note > that this is not a skinning issue, rather a decision to display or not > display fields entirely based on the product-selected field scheme. For > example, a field scheme may show "Version" while another may not. Never mind. Yes, I agree - the skin methods to provide a sample of "how to do this." The question I'm asking is for clarification from Max/Fred/Myk/Dave on what direction they would like to see it go... Kevin Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. > > > -----Original Message----- > > From: Tosh, Michael J [mailto:michael.j.tosh at lmco.com] > > Sent: Thursday, November 15, 2007 11:00 AM > > To: Benton, Kevin; developers at bugzilla.org > > Subject: RE: Bug Field Scheme Templates > > > > While I can't speak for the developers, I'd like to suggest that you > > look at it like a full template skin. > > > > template//skins// > > > > Where if the product uses a skin, attempt to load the skin's template > > first, and if it isn't there, use the > > template//default/ instead. > > > > > > > > -----Original Message----- > > From: dev-apps-bugzilla-bounces at lists.mozilla.org > > [mailto:dev-apps-bugzilla-bounces at lists.mozilla.org] On Behalf Of > > Benton, Kevin > > Sent: Thursday, November 15, 2007 12:46 PM > > To: developers at bugzilla.org > > Subject: Bug Field Scheme Templates > > > > In order to ask my question, I need to give a little background: > > > > > > > > AMD is in the process of coding "bug field schemes" - the ability to > > make a list of fields that are available by product. An installation > > will have the ability to have several field schemes, each of which can > > be used by multiple products allowing product owners to determine the > > set of fields that make the most sense for that product. To > facilitate > > that, we're looking into how we extend the templating system so that > it > > knows where to find the appropriate template for the given product. > > > > > > > > The question is, what is the best way to add field schemes into the > > template directory structure? We're considering the following: > > > > > > > > template/en/default/bug/fs_/... > > > > > > > > or > > > > > > > > template/en/field_scheme/fs_/... > > > > > > > > Considering that this code may get contributed back to the community > > (notwithstanding what others may already be doing), what is most > likely > > to be accepted at this point? I ask because we are committed to > > completing our own field scheme implementation before month end and > I'd > > like it to be as close to "acceptable" to the community at large as > > possible. > > > > > > > > Kevin > > > > > > Kevin Benton > > MySQL DBA #5739 > > Senior Software Developer > > CAD Global Infrastructure Flow Services > > Advanced Micro Devices > > 2950 E Harmony Rd > > Fort Collins, CO 80528 > > > > > > > > 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. > > > > > > > > _______________________________________________ > > dev-apps-bugzilla mailing list > > dev-apps-bugzilla at lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > > > > > > - > To view or change your list settings, click here: > > From mkanat at bugzilla.org Thu Nov 15 19:57:23 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 15 Nov 2007 11:57:23 -0800 Subject: Bug Field Scheme Templates In-Reply-To: References: Message-ID: <20071115115723.430190eb@es-compy> On Thu, 15 Nov 2007 09:45:48 -0800 "Benton, Kevin" wrote: > The question is, what is the best way to add field schemes into the > template directory structure? Similar to what Michael suggests, I'd suggest naming the schemes and making them full skins, as though the PROJECT environment variable were set. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From wlk999 at gmail.com Sun Nov 11 10:38:29 2007 From: wlk999 at gmail.com (Weiling Ke) Date: Sun, 11 Nov 2007 02:38:29 -0800 Subject: Open Source Software Research Message-ID: Dear Open Source Software Participant: You are invited to participate in a OSS research survey conducted by Professor Weiling Ke at Clarkson University and Professor Ping Zhang at Syracuse University. Currently, we are examining factors that motivate people's participation in the Open Source Software (OSS) community. Your response is critical to our research and will be highly appreciated! Here is a link to the survey: http://www.surveymonkey.com/s.aspx?sm=Kz7dhISrOW7hQOJBpr4ysA_3d_3d Thanks for your participation! Sincerely yours, Weiling Ke _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From michael.j.tosh at lmco.com Thu Nov 15 18:00:15 2007 From: michael.j.tosh at lmco.com (Tosh, Michael J) Date: Thu, 15 Nov 2007 13:00:15 -0500 Subject: Bug Field Scheme Templates In-Reply-To: References: Message-ID: While I can't speak for the developers, I'd like to suggest that you look at it like a full template skin. template//skins// Where if the product uses a skin, attempt to load the skin's template first, and if it isn't there, use the template//default/ instead. -----Original Message----- From: dev-apps-bugzilla-bounces at lists.mozilla.org [mailto:dev-apps-bugzilla-bounces at lists.mozilla.org] On Behalf Of Benton, Kevin Sent: Thursday, November 15, 2007 12:46 PM To: developers at bugzilla.org Subject: Bug Field Scheme Templates In order to ask my question, I need to give a little background: AMD is in the process of coding "bug field schemes" - the ability to make a list of fields that are available by product. An installation will have the ability to have several field schemes, each of which can be used by multiple products allowing product owners to determine the set of fields that make the most sense for that product. To facilitate that, we're looking into how we extend the templating system so that it knows where to find the appropriate template for the given product. The question is, what is the best way to add field schemes into the template directory structure? We're considering the following: template/en/default/bug/fs_/... or template/en/field_scheme/fs_/... Considering that this code may get contributed back to the community (notwithstanding what others may already be doing), what is most likely to be accepted at this point? I ask because we are committed to completing our own field scheme implementation before month end and I'd like it to be as close to "acceptable" to the community at large as possible. Kevin Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From manaham at yahoo.com Mon Nov 19 05:11:40 2007 From: manaham at yahoo.com (Joe) Date: Sun, 18 Nov 2007 21:11:40 -0800 Subject: Get A Top 5 Google Ranking In Under 30 Days Message-ID: Get A Top 5 Google Ranking In Under 30 Days http://seoplacement.100webspace.net/seo/seo-optimization/best_seo_software.html _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From justdave at bugzilla.org Wed Nov 21 02:34:38 2007 From: justdave at bugzilla.org (David Miller) Date: Tue, 20 Nov 2007 21:34:38 -0500 Subject: Japanese Localization of Bugzilla? Message-ID: <4743993E.1000603@bugzilla.org> The domain which was hosting the Japanese localizations of Bugzilla, as well as the domain hosting the personal home page of the maintainer, appear to have been taken over by a domain shark. Does anyone know if there's any work still done on a Japanese localization of Bugzilla, and if so, where we might direct people to find it? -- 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 mkanat at bugzilla.org Fri Nov 23 07:13:50 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 22 Nov 2007 23:13:50 -0800 Subject: Bugzilla Strings Now Have UTF-8 Bit Set Message-ID: <20071122231350.04a3f1d9@es-compy> So, everybody should know that the following bug was just fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=363153 For anybody who doesn't understand the world of Perl and Unicode, it can be kind of a complex subject, but in short: this is going to make our lives a lot easier. Here's a brief explanation: When you're using UTF-8, in many written languages a single character is more than one byte. This means that length($string), if it measures bytes, doesn't really return what we'd think of as the "length" of the string. For example, Ins?de? looks like seven characters, but it's 10 bytes long. Now, in Bugzilla, when the utf8 parameter is turned on, all strings are treated as characters instead of bytes, so length($string) will return the correct "length" of the string, not the number of bytes in it. Strings going into the database and coming out of the database are automatically considered to be UTF-8. 7-bit ASCII strings (containing only values of 127 or below) are still treated as bytes, because a byte and a character are the same thing in ASCII. If for some reason you need to find out if a string is utf-8 or just ASCII, you can use "utf8::is_utf8($string)". You don't need to "use utf8" to do that--the function is always available as part of the Perl core. However, you should never have to worry about that anymore. All Bugzilla code should now automatically do the "right thing" without you ever having to think about whether or not you're dealing with Unicode, thanks to the patch just checked in in the above bug. Since all of this only works with the "utf8" flag on, anybody anybody who wants to use a non-ASCII language in Bugzilla should be using the "utf8" flag. This has always been true (as long as we've had the utf8 flag), but since Bugzilla now works even *better* with non-ASCII languages, it's even *more* true. I just wanted to let you know about all this, and the details of Unicode in Perl, in case for some reason somebody needs to know these things in the future. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Fri Nov 23 12:22:38 2007 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Nov 2007 12:22:38 +0000 Subject: Bugzilla Strings Now Have UTF-8 Bit Set In-Reply-To: <20071122231350.04a3f1d9@es-compy> References: <20071122231350.04a3f1d9@es-compy> Message-ID: <4746C60E.1010806@mozilla.org> Max Kanat-Alexander wrote: > However, you should never have to worry about that anymore. All > Bugzilla code should now automatically do the "right thing" without you > ever having to think about whether or not you're dealing with Unicode, > thanks to the patch just checked in in the above bug. I never thought about that in the past anyway. So I should just keep on not thinking about it? :-) Gerv From mkanat at bugzilla.org Fri Nov 23 20:31:44 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Nov 2007 12:31:44 -0800 Subject: Bugzilla Strings Now Have UTF-8 Bit Set In-Reply-To: <4746C60E.1010806@mozilla.org> References: <20071122231350.04a3f1d9@es-compy> <4746C60E.1010806@mozilla.org> Message-ID: <20071123123144.62a0d08a@es-compy> On Fri, 23 Nov 2007 12:22:38 +0000 Gervase Markham wrote: > I never thought about that in the past anyway. So I should just keep > on not thinking about it? :-) Hahahaha, yeah, basically. :-) It's only actually important to think about if we add some new module that doesn't work with UTF-8 correctly--then sometimes we have to do clever things to make it work right. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From silver7 at gmail.com Tue Nov 27 07:55:04 2007 From: silver7 at gmail.com (Micah Breitenstein) Date: Mon, 26 Nov 2007 23:55:04 -0800 Subject: Self-Introduction: Micah Breitenstein Message-ID: <314c83b0711262355t5636df76j221b269f3f1980e7@mail.gmail.com> Hi all I'm a Software Quality Assurance Eng who works in the SF Bay area. I have experience setting up Bugzilla, skinning it and I am also responsible for administering my company's Bugzilla instances. If I can help out in any way please let me know. This is the first time I have joined a open source project. Thanks -Micah Breitenstein From mkanat at bugzilla.org Tue Nov 27 08:06:06 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 27 Nov 2007 00:06:06 -0800 Subject: Self-Introduction: Micah Breitenstein In-Reply-To: <314c83b0711262355t5636df76j221b269f3f1980e7@mail.gmail.com> References: <314c83b0711262355t5636df76j221b269f3f1980e7@mail.gmail.com> Message-ID: <20071127000606.2566dbf0@es-compy> On Mon, 26 Nov 2007 23:55:04 -0800 "Micah Breitenstein" wrote: > If I can help out in any way please let me know. This is the first > time I have joined a open source project. Hey Micah! Sure, we'd be happy to have some help! Do you have any experience coding in Perl? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From silver7 at gmail.com Tue Nov 27 08:45:53 2007 From: silver7 at gmail.com (Micah Breitenstein) Date: Tue, 27 Nov 2007 00:45:53 -0800 Subject: Self-Introduction: Micah Breitenstein In-Reply-To: <20071127000606.2566dbf0@es-compy> References: <314c83b0711262355t5636df76j221b269f3f1980e7@mail.gmail.com> <20071127000606.2566dbf0@es-compy> Message-ID: <314c83b0711270045o42843b71q2e0e546745714eb@mail.gmail.com> I do have experience coding in Perl. I'm a bit rusty and will be leveraging my O'Reilly books. I've got a unlimited access account to the O'Reilly Online Safari Library, and enjoy bettering my technical skills. At the moment I am trying to wrap my head around CGI as I'd like to auto-populate my added custom fields prior to bug submission. I envision pushing a button, then based upon the supplied system's name, populate all given custom fields with info residing in the company's Access database. Tomorrow I plan to read more of "The Bugzilla Guide - 3.1.2 Development Release" I've been able to add a new button called "Populate" to the new new bug submission template and regenerate the templates. Any ideas would be most welcome. -Micah On Nov 27, 2007 12:06 AM, Max Kanat-Alexander wrote: > On Mon, 26 Nov 2007 23:55:04 -0800 "Micah Breitenstein" > wrote: > > If I can help out in any way please let me know. This is the first > > time I have joined a open source project. > > Hey Micah! Sure, we'd be happy to have some help! > > Do you have any experience coding in Perl? > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > - > To view or change your list settings, click here: > > From mkanat at bugzilla.org Tue Nov 27 08:57:55 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 27 Nov 2007 00:57:55 -0800 Subject: Self-Introduction: Micah Breitenstein In-Reply-To: <314c83b0711270045o42843b71q2e0e546745714eb@mail.gmail.com> References: <314c83b0711262355t5636df76j221b269f3f1980e7@mail.gmail.com> <20071127000606.2566dbf0@es-compy> <314c83b0711270045o42843b71q2e0e546745714eb@mail.gmail.com> Message-ID: <20071127005755.4d34aceb@es-compy> On Tue, 27 Nov 2007 00:45:53 -0800 "Micah Breitenstein" wrote: > I do have experience coding in Perl. I'm a bit rusty and will be > leveraging my O'Reilly books. I've got a unlimited access account to > the O'Reilly Online Safari Library, and enjoy bettering my technical > skills. Okay! :-) There's lots of areas you can help in other than programming, too, if you want. We always need people to help with QA, when that needs to be done. Or you could help with the documentation, because that always needs some love! :-) > At the moment I am trying to wrap my head around CGI as I'd like to > auto-populate my added custom fields prior to bug submission. I > envision pushing a button, then based upon the supplied system's name, > populate all given custom fields with info residing in the company's > Access database. You could probably use some DBD:: thing plus $cgi->param('cf_field_name', $value); Feel free to come into IRC and ask us about it. http://wiki.mozilla.org/Bugzilla:Communicate -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From silver7 at gmail.com Tue Nov 27 09:04:24 2007 From: silver7 at gmail.com (Micah Breitenstein) Date: Tue, 27 Nov 2007 01:04:24 -0800 Subject: Self-Introduction: Micah Breitenstein In-Reply-To: <20071127005755.4d34aceb@es-compy> References: <314c83b0711262355t5636df76j221b269f3f1980e7@mail.gmail.com> <20071127000606.2566dbf0@es-compy> <314c83b0711270045o42843b71q2e0e546745714eb@mail.gmail.com> <20071127005755.4d34aceb@es-compy> Message-ID: <314c83b0711270104x39df574bp29a682409a07ce22@mail.gmail.com> Thanks for you quick input! I'll hit you all up on chat once I am rested. g-night. =') -Micah On Nov 27, 2007 12:57 AM, Max Kanat-Alexander wrote: > On Tue, 27 Nov 2007 00:45:53 -0800 "Micah Breitenstein" > wrote: > > I do have experience coding in Perl. I'm a bit rusty and will be > > leveraging my O'Reilly books. I've got a unlimited access account to > > the O'Reilly Online Safari Library, and enjoy bettering my technical > > skills. > > Okay! :-) There's lots of areas you can help in other than > programming, too, if you want. We always need people to help with QA, > when that needs to be done. Or you could help with the documentation, > because that always needs some love! :-) > > > At the moment I am trying to wrap my head around CGI as I'd like to > > auto-populate my added custom fields prior to bug submission. I > > envision pushing a button, then based upon the supplied system's name, > > populate all given custom fields with info residing in the company's > > Access database. > > You could probably use some DBD:: thing plus > $cgi->param('cf_field_name', $value); > > Feel free to come into IRC and ask us about it. > > http://wiki.mozilla.org/Bugzilla:Communicate > > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > - > To view or change your list settings, click here: > > From craig5 at pobox.com Thu Nov 29 00:39:07 2007 From: craig5 at pobox.com (Craig) Date: Wed, 28 Nov 2007 16:39:07 -0800 Subject: email interface into a module? Message-ID: <474E0A2B.4020907@pobox.com> I am using Bugzilla 3.0.1 (yes, I am upgrading to 3.0.2 this week. ;> ) We would like to enable the "email interface". However, our mail service is outsourced. I have written a simple script to talk to mail server (via IMAP) and grab the messages. Obviously, I can then use "email_in.pl" via a system call. But, that seems kinda klunky... (But, it is a good short-term solution.) I don't want to re-write the parsing routines or the logic checks. (And thus use the XML service on the bugzilla server.) I want to be able to *get* the emails in a custom way, do my own logic checks, and then have something else to parse the body and load it into the DB. So, what if the bulk of the "email_in.pl" code was moved into a module (Bugzilla::EmailIn???)? And then email_in.pl was changed to be just a "wrapper" that would read from STDIN, etc. But, the bulk of the work would be in the module (and thus available as an API). I am a pretty decent perl programmer would be more than willing to code this up... but, wanted to ask if this sounds like a reasonable course. TIA! Craig From cchan at mvista.com Thu Nov 29 00:51:03 2007 From: cchan at mvista.com (Clement Chan) Date: Wed, 28 Nov 2007 16:51:03 -0800 Subject: email interface into a module? In-Reply-To: <474E0A2B.4020907@pobox.com> References: <474E0A2B.4020907@pobox.com> Message-ID: <1196297463.4314.45.camel@bugtest.mvista.com> The project that I am working on uses a fetchmail daeman to fetch the bugs from the email server, and then calls procmail to run email_in.pl. It is pretty neat and can be done. However it is run inside the firewall, so security wasn't a major issue. The email password can be exposed on the internet though. Procmail supports conditional parsing every time when it is called. - Clement On Wed, 2007-11-28 at 16:39 -0800, Craig wrote: > I am using Bugzilla 3.0.1 (yes, I am upgrading to 3.0.2 this week. ;> ) > > We would like to enable the "email interface". However, our mail service > is outsourced. I have written a simple script to talk to mail server > (via IMAP) and grab the messages. > > Obviously, I can then use "email_in.pl" via a system call. But, that > seems kinda klunky... (But, it is a good short-term solution.) > > I don't want to re-write the parsing routines or the logic checks. (And > thus use the XML service on the bugzilla server.) I want to be able to > *get* the emails in a custom way, do my own logic checks, and then have > something else to parse the body and load it into the DB. > > So, what if the bulk of the "email_in.pl" code was moved into a module > (Bugzilla::EmailIn???)? > > And then email_in.pl was changed to be just a "wrapper" that would read > from STDIN, etc. But, the bulk of the work would be in the module (and > thus available as an API). > > I am a pretty decent perl programmer would be more than willing to code > this up... but, wanted to ask if this sounds like a reasonable course. > > TIA! > Craig > - > To view or change your list settings, click here: > From mkanat at bugzilla.org Thu Nov 29 03:05:42 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 28 Nov 2007 19:05:42 -0800 Subject: email interface into a module? In-Reply-To: <474E0A2B.4020907@pobox.com> References: <474E0A2B.4020907@pobox.com> Message-ID: <20071128190542.44b6804f@es-compy> On Wed, 28 Nov 2007 16:39:07 -0800 Craig wrote: > So, what if the bulk of the "email_in.pl" code was moved into a module > (Bugzilla::EmailIn???)? It might work. Actually, a lot of the code needs to be re-written to use Bugzilla::Bug anyhow. It's possible that a lot of the code could go into Bugzilla::Bug and be generally useful. Something like Bugzilla::Bug::update_from_params might be good to have. We have to finish bringing process_bug.cgi into Bugzilla::Bug first, though (which we're almost done with, in HEAD). -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 29 03:51:42 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 28 Nov 2007 19:51:42 -0800 Subject: YUI Message-ID: <20071128195142.1cca90fe@es-compy> I just checked in our first patch that uses YUI, the Yahoo JavaScript Library: https://bugzilla.mozilla.org/show_bug.cgi?id=397099 Here's what you should know about YUI, as we're going to use it in Bugzilla: * All JavaScript that can use YUI should do so, instead of writing custom code. * YUI ships with a skin for its various elements, called "sam". All HTML elements that contain a YUI object should have class="yui-skin-sam" in order to render correctly. * Stable versions of Bugzilla may not upgrade to new major releases of YUI (say, from 2.3 -> 2.4) but may upgrade to bug-fix releases (say, from 2.3.0 -> 2.3.1). * We are currently using YUI 2.3.1. If you upgrade any part of YUI to a newer version, you must upgrade all of it to that newer version. * YUI is separated out into many files. We only include the files in Bugzilla that we actually use. * The files are set up in our directory structure in such a way that they can be skinned with our skinning system. * We use the css and image files from the YUI "build/assets/" directory, for anybody else who's going to be adding new parts of YUI in the future. * When you add a CSS file, you have to make sure that any images referenced in that CSS (usually png files) have the correct path. In the standard YUI, they are listed in the CSS with a relative path that doesn't work for us. * We use the "minified" version of the YUI files, where all spaces, comments, and newlines have been removed. This makes them load faster. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 29 08:04:01 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 29 Nov 2007 00:04:01 -0800 Subject: The Responsibilities of Committers Message-ID: <20071129000401.0893348f@es-compy> I just wrote this blog post, and I think it's relevant to everybody on the list, particularly people who are contributors to the codebase: http://avatraxiom.livejournal.com/69140.html -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From craig5 at pobox.com Thu Nov 29 22:13:59 2007 From: craig5 at pobox.com (Craig) Date: Thu, 29 Nov 2007 14:13:59 -0800 Subject: autoconf Message-ID: <474F39A7.8000106@pobox.com> Ok, I'm new to the list, so forgive me if this is a FAQ... Why doesn't the Bugzilla install use autoconf? Just copying the directory obviously works, but wouldn't it be "cleaner" for people to just run: ./configure make install I know it seems like a lot of overhead in the current system, but at some point the install process may be a little more complicated. At the very least, we could remove the README, UPGRADING, etc. files in a "working dir". Thoughts? Also, is there any way to search the mail list archives? It seems to require an email address to browse. I believe this means that Google won't index them. Craig From justdave at bugzilla.org Thu Nov 29 22:25:05 2007 From: justdave at bugzilla.org (David Miller) Date: Thu, 29 Nov 2007 14:25:05 -0800 Subject: autoconf In-Reply-To: <474F39A7.8000106@pobox.com> References: <474F39A7.8000106@pobox.com> Message-ID: <474F3C41.7000000@bugzilla.org> Craig wrote on 11/29/07 2:13 PM: > Also, is there any way to search the mail list archives? It seems to > require an email address to browse. I believe this means that Google > won't index them. Throw in whatever address you want... it's just to keep the email harvesters out, since it doesn't obfuscate the addresses in the posts. This list is gatewayed to a newsgroup now, too. More recent posts (within the last month or two) can be found in http://groups.google.com/group/mozilla.dev.apps.bugzilla -- 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 mkanat at bugzilla.org Thu Nov 29 22:39:24 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 29 Nov 2007 14:39:24 -0800 Subject: autoconf In-Reply-To: <474F39A7.8000106@pobox.com> References: <474F39A7.8000106@pobox.com> Message-ID: <20071129143924.4ecb3e70@es-compy> On Thu, 29 Nov 2007 14:13:59 -0800 Craig wrote: > Why doesn't the Bugzilla install use autoconf? Well, mostly because we don't need it. Everything in Bugzilla goes into one directory. Distros can separate it out, but they have packages for that. Also, it's an extremely unfamiliar idiom for Windows users, who don't even have make installed or easily available. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From craig5 at pobox.com Thu Nov 29 23:39:00 2007 From: craig5 at pobox.com (Craig) Date: Thu, 29 Nov 2007 15:39:00 -0800 Subject: search mailing list (was "autoconf") In-Reply-To: <474F3C41.7000000@bugzilla.org> References: <474F39A7.8000106@pobox.com> <474F3C41.7000000@bugzilla.org> Message-ID: <474F4D94.6070308@pobox.com> David Miller wrote: > Craig wrote on 11/29/07 2:13 PM: > This list is gatewayed to a newsgroup now, too. More recent posts > (within the last month or two) can be found in > http://groups.google.com/group/mozilla.dev.apps.bugzilla Can that be put in a FAQ somewhere? Also, the search box on the developers page seems to be broken: http://www.bugzilla.org/developers/ (Down a little under "Mailing List".) I tried searching for "email" and got no results. (The same search on google groups gave plenty of results.) A very minor issue, but thought you may like to know. :) From gerv at mozilla.org Fri Nov 30 19:56:27 2007 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 30 Nov 2007 19:56:27 +0000 Subject: Bugzilla directed giving Message-ID: People, As Dave has blogged: http://www.justdave.net/dave/2007/11/20/you-can-donate-money-to-bugzilla-now/ the Bugzilla directed giving program is now live. Anyone can donate money to the MoFo earmarked for Bugzilla development. And what he didn't mention is that, up until the end of the year, the MoFo will match donations 2-for-1 - so donate $100, and you've effectively donated $300. But I just want to point out that the MoFo is unlikely to go out and directly solicit Bugzilla-specific donations. For this program to be a success, the Bugzilla community needs to take hold of it and run with it. So perhaps we might want to discuss how to do that :-) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla