From fedrushkov at users.sourceforge.net Sun Feb 1 00:16:59 2009 From: fedrushkov at users.sourceforge.net (Vitaly Fedrushkov) Date: Sun, 01 Feb 2009 05:16:59 +0500 Subject: word forms for terms.Bugzilla needed In-Reply-To: References: Message-ID: <4984E9FB.8000800@users.sourceforge.net> Necmettin Begiter wrote: [quoted in full as crossposted to localizers at bugzilla.org] > Hello all, I'm new to this list (but not Bugzilla translation). I am a > developer working for the Pardus GNU/Linux project and I've just recently > started translation Bugzilla 3.2 into Turkish as we will switch to 3.2 as > soon as I'm done. > First, some background information to the issue: > Turkish language has two very interesting features that makes it a IMHO very > un-mechanical language: Its written and spoken form is the same and the > letters (=sounds) used in suffixes in word formation differs according to > the letters (=sounds) preceding the letters to be added. Let me explain > them in the simplest form I can: > It's written and spoken form is the same: > Ali is read as /ali/ (=Alpha Lima India) > Book is read as /book/ (consider the /o/s in door) > On to the second issue, different letters (=sounds) in the suffix for words > with different endings: > Bugzilla'n?n (=Bugzilla's) > Ali'nin (=Ali's) > Notice the "n?n"-"nin" difference here. > Bugzilla'da (=in Bugzilla) > Eski?ehir'de (=in Eski?ehir) > Also notice the "da"-"de" difference here. Siarhei once provided a similar example, which leads to terms.bug customizarion being useless in Belarusian due to long distance dependencies, even in situations where gender is not changed. > The conclusion: > I need to add variables like terms.BugzillaNom, BugzillaAcc, BugzillaDat, > BugzillaLoc, BugzillaAbl, BugzillaGen to the appropriate file (which, I'm > guessing, is global/variables.none.tmpl or some other file in global/) to > make them available to the Bugzilla installation that will be employed. As > Turkish has these two issues I've mentioned above, I can not translate > these noun forms seperately nor can I correctly use in my translations > suffixes like 'nin, 'n?n, 'da, 'de .. without knowing the value of > terms.Bugzilla. So in its current form, it is not possible to have an > optimum Turkish translation of Bugzilla. Yes you should put the whole paradigm of terms.Bugzilla into global/variables.none.tmpl, as it is done for terms.bug in many languages. Include possessive case also (like terms.Bugzilla_nin to keep text more readable). Then you use correct form within templates. Customizers willing to rename Bugzilla should also change the paradigm accordingly. > On to the questions: > Is it possible that the mentioned variables be added to Bugzilla code (3.2 > if possible)? > If so, if these variables are put into global/*whatever*, will/can they be > backported to 3.2 or 3.2.1, or will/can they be included in 3.4 and later? These variables are used only by template/tr/* so having them in template/tr/default/global/variables.none.tmpl is sufficient. English templates do not need these, and other languages already have different sets. Good point: until you translate 100% of your templates, you may want to keep terms.bug as 'bug' and use (for example) terms.bug_nom for Turkish term. This way you will avoid ugly renderings where English messages refer to localized terms. > Questions/ comments/ requests welcome. This is sort of a cross-posting (also > reported as a bug in Bugzilla's Bugzilla) but I needed clarification and > this list probably has a larger user-base. Regards, Vitaly. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From vitaly.fedrushkov at gmail.com Mon Feb 2 09:28:24 2009 From: vitaly.fedrushkov at gmail.com (SnowyOwl) Date: Mon, 2 Feb 2009 01:28:24 -0800 (PST) Subject: Bugzilla 3.3.2+ terminology Message-ID: <5f441f83-6fd2-4c2b-b475-1d3660445c92@x16g2000prn.googlegroups.com> 3.3.2 is approaching release. While no l12y problems were introduced since 3.2, some fine terminology issues may arise, in connection to inter-Bugzilla interaction features. Before, 'URL' has single meaning as 'hyperlink to page demonstrating a bug' (browser bug tracking legacy). Now we have 'Bug URL' as 'reference to bug object in some Bugzilla instance'. Care should be taken when choosing meanings from loose concept of URL/hyperlink/ reference. Also, terms.Bugzilla is supposed to mean 'proper name of this Bugzilla instance' and does not apply when talking about 'See also in other Bugzilla instances'. 'Bugzilla' as a bare word is probably no longer a typo, but the name of technology, not instance. Regards, Vitaly. _______________________________________________ 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 Tue Feb 3 22:06:19 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 03 Feb 2009 23:06:19 +0100 Subject: Bugzilla meeting next Tuesday, February 10, 2009 at 11:00 PST (19:00 GMT, 20:00 CET) Message-ID: <4988BFDB.40903@gmail.com> Hi all, Our next Bugzilla meeting will take place next Tuesday, February 10, at 11:00 PST in the #bugzilla-meeting channel on IRC. Everyone is free to attend, as usual. We will of course talk about the recent releases (7 releases in less than 12 hours!) and the coming 3.4rc1 release. The agenda is available at https://wiki.mozilla.org/Bugzilla:Meetings See you next week, LpSolit From mkanat at bugzilla.org Wed Feb 4 22:23:37 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 4 Feb 2009 14:23:37 -0800 Subject: Avoiding Future Security Bug Regressions Message-ID: <20090204142337.5e5986d4@bugzilla.org> We've seen several regressions from the security bugs that were fixed in 3.2.1, 3.0.7, 2.22.7, and 3.3.2. I see two causes for this: 1) Many invasive security security bugs were checked in at once immediately before a release. 2) We did not release our point releases quickly enough after each individual security bug was fixed, so many bugs were fixed in a single release. In order to avoid future regressions of a similar nature, I am proposing the following re-organization of the release process: 1) Once any security bug is fixed, we should try to release within the month. We should generally not put a security release on hold for other security patches or other bug fixes. And the following policies: 1) No matter what, no more than one *invasive* security patch per release. 2) All invasive security patches should be tested on bugzilla.mozilla.org for at least 24 hours before a release. An example of an invasive security patch would be the attachment patch we just did, or the fixing of the process_bug CSRF that we just did. If there is no objection, I will write these up on the Wiki and they will become the official policy of the Bugzilla Project by Wednesday of next week. Sound good? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Wed Feb 4 23:09:07 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 05 Feb 2009 00:09:07 +0100 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <20090204142337.5e5986d4@bugzilla.org> References: <20090204142337.5e5986d4@bugzilla.org> Message-ID: <498A2013.9030104@gmail.com> Le 04. 02. 09 23:23, Max Kanat-Alexander a ?crit : > I see two causes for this: > > 1) Many invasive security security bugs were checked in at > once immediately before a release. The number of security bugs has nothing to do here. We could have checked in only one and still triggered the problems reported. > If there is no objection, I will write these up on the > Wiki and they will become the official policy of the Bugzilla > Project by Wednesday of next week. There is an objection: I don't want this policy to be written in rock. What you suggest wouldn't have prevented the regressions to occur, and bmo is probably not going to be upgraded all the time to test a security patch. It's the role of the patch author and of the reviewer to test patches as well as possible, which we did. Also, I think this kind of discussion should first take place elsewhere before being posted here. LpSolit From mkanat at bugzilla.org Wed Feb 4 23:21:49 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 4 Feb 2009 15:21:49 -0800 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <498A2013.9030104@gmail.com> References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> Message-ID: <20090204152149.2f9e2f48@bugzilla.org> On Thu, 05 Feb 2009 00:09:07 +0100 "Fr?d?ric Buclin" wrote: > The number of security bugs has nothing to do here. We could have > checked in only one and still triggered the problems reported. Well, for example, calling srand() at compile time happened because of the process_bug CSRF patch, but it was particularly bad because we were using tokens to protect private attachments. > What you suggest wouldn't have prevented the regressions to > occur, It absolutely would have. We did a release within 9 hours--24 hours would have caught the most important problem. If we said "24 hours without a major regression from the security patches" it would have caught all regressions that we've found so far. > and bmo is probably not going to be upgraded all the time to > test a security patch. I don't know if you're just being argumentative on purpose, or if there is a communication problem, but what I wrote above was clearly that the policy would be limited to invasive patches. > Also, I think this kind of discussion should first take place > elsewhere before being posted here. I figured that you would reply along with everybody else here, and I wanted to write it as an email, and I felt it was something that the community should be exposed to the discussion on. I also didn't think it was that controversial. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From justdave at bugzilla.org Wed Feb 4 23:50:25 2009 From: justdave at bugzilla.org (David Miller) Date: Wed, 04 Feb 2009 18:50:25 -0500 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <20090204152149.2f9e2f48@bugzilla.org> References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> <20090204152149.2f9e2f48@bugzilla.org> Message-ID: <498A29C1.7010203@bugzilla.org> Max Kanat-Alexander wrote on 2/4/09 6:21 PM: > It absolutely would have. We did a release within 9 hours--24 > hours would have caught the most important problem. If we said "24 > hours without a major regression from the security patches" it would > have caught all regressions that we've found so far. > >> and bmo is probably not going to be upgraded all the time to >> test a security patch. > > I don't know if you're just being argumentative on purpose, or > if there is a communication problem, but what I wrote above was clearly > that the policy would be limited to invasive patches. This particular patch would have been on bmo about a month earlier if our management had their way. It was purposefully withheld from being deployed on bmo until after the security release was ready to go out because the nature of the patch made it obvious that the fix had been applied and would immediately clue in anyone who hadn't already realized it what would need to be done to exploit other Bugzilla installations that didn't have it yet. -- 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 Feb 5 02:11:21 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 4 Feb 2009 18:11:21 -0800 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <498A29C1.7010203@bugzilla.org> References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> <20090204152149.2f9e2f48@bugzilla.org> <498A29C1.7010203@bugzilla.org> Message-ID: <20090204181121.21c0a669@bugzilla.org> On Wed, 04 Feb 2009 18:50:25 -0500 David Miller wrote: > This particular patch would have been on bmo about a month earlier if > our management had their way. Yeah, that's one reason why I think bmo is a good test bed, because the security posture of Mozilla has stepped up so much recently that I imagine they would welcome the opportunity to have early fixes for any Bugzilla security problems (even if just 24 hours early). > It was purposefully withheld from being > deployed on bmo until after the security release was ready to go out > because the nature of the patch made it obvious that the fix had been > applied and would immediately clue in anyone who hadn't already > realized it what would need to be done to exploit other Bugzilla > installations that didn't have it yet. Yeah. That's why for things like that, I want to do it when the release is basically entirely ready to go, and just test it for 24 hours. That would have caught the stuff we've found since the 3.2.1 release. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From vitaly.fedrushkov at gmail.com Thu Feb 5 10:26:22 2009 From: vitaly.fedrushkov at gmail.com (SnowyOwl) Date: Thu, 5 Feb 2009 02:26:22 -0800 (PST) Subject: Avoiding Future Security Bug Regressions References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> <20090204152149.2f9e2f48@bugzilla.org> Message-ID: <705f06b0-2245-491d-88ca-7f4c8a7ed911@g39g2000pri.googlegroups.com> On Feb 5, 03:23, Max Kanat-Alexander wrote: > 2) All invasive security patches should be tested on > bugzilla.mozilla.org for at least 24 hours before a release. On Feb 5, 04:50, David Miller wrote: > This particular patch would have been on bmo about a month earlier if > our management had their way. ?It was purposefully withheld from being > deployed on bmo until after the security release was ready to go out > because the nature of the patch made it obvious that the fix had been > applied and would immediately clue in anyone who hadn't already realized > it what would need to be done to exploit other Bugzilla installations > that didn't have it yet. This is a question of b.m.o source version control being open OR closed (at least at times) to avoid premature disclosure. If we manage to keep a "private branch" in future DVCS, namely, commit all patches except security sensitive into open branch and run b.m.o from private branch -- this may satisfy both sides. No, this does not eliminate chance of disclosure anyway, as http traffic is still open to analysis. But that's not the same as being aware of, and seeing the patch itself. Regards, Vitaly. _______________________________________________ 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 Thu Feb 5 11:04:16 2009 From: justdave at bugzilla.org (David Miller) Date: Thu, 05 Feb 2009 06:04:16 -0500 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <705f06b0-2245-491d-88ca-7f4c8a7ed911@g39g2000pri.googlegroups.com> References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> <20090204152149.2f9e2f48@bugzilla.org> <705f06b0-2245-491d-88ca-7f4c8a7ed911@g39g2000pri.googlegroups.com> Message-ID: <498AC7B0.1020100@bugzilla.org> SnowyOwl wrote on 2/5/09 5:26 AM: > This is a question of b.m.o source version control being open OR > closed (at least at times) to avoid premature disclosure. > > If we manage to keep a "private branch" in future DVCS, namely, commit > all patches except security sensitive into open branch and run b.m.o > from private branch -- this may satisfy both sides. bmo is already on a DVCS branch of its own (that could have been closed if needed). The point was that the fix was blatently obvious (you wound up on a different domain name), and anyone with a slight knowledge of web security would probably realize the reason why pretty quickly. There's actually been several times in the past when we've had security patches applied on bmo before they were publicly available. Most of the time they're not user-visible issues (sanitizing user input, etc). This particular one just didn't lend itself well to that. -- 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 bbaetz at acm.org Thu Feb 5 16:19:59 2009 From: bbaetz at acm.org (Bradley Baetz) Date: Thu, 5 Feb 2009 10:19:59 -0600 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <498AC7B0.1020100@bugzilla.org> References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> <20090204152149.2f9e2f48@bugzilla.org> <705f06b0-2245-491d-88ca-7f4c8a7ed911@g39g2000pri.googlegroups.com> <498AC7B0.1020100@bugzilla.org> Message-ID: <99435f5b0902050819r41d76670y9ce1c8e478553c43@mail.gmail.com> On Thu, Feb 5, 2009 at 5:04 AM, David Miller wrote: > SnowyOwl wrote on 2/5/09 5:26 AM: >> This is a question of b.m.o source version control being open OR >> closed (at least at times) to avoid premature disclosure. >> >> If we manage to keep a "private branch" in future DVCS, namely, commit >> all patches except security sensitive into open branch and run b.m.o >> from private branch -- this may satisfy both sides. > > bmo is already on a DVCS branch of its own (that could have been closed > if needed). The point was that the fix was blatently obvious (you wound > up on a different domain name), and anyone with a slight knowledge of > web security would probably realize the reason why pretty quickly. What we could have done is to put out an rc, with the promise that the only difference to the final would be any regression fixes from the security patch (and the version number bump). Admins on public instances could have upgraded and would have been no worse off, while internal/less critical installations could have waited. In reality, bmo is our test suite. Thats not a good thing (and I don't think mozilla likes it as much as they used to), but its the reality. Bradley From mkanat at bugzilla.org Thu Feb 5 18:18:41 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 5 Feb 2009 10:18:41 -0800 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <99435f5b0902050819r41d76670y9ce1c8e478553c43@mail.gmail.com> References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> <20090204152149.2f9e2f48@bugzilla.org> <705f06b0-2245-491d-88ca-7f4c8a7ed911@g39g2000pri.googlegroups.com> <498AC7B0.1020100@bugzilla.org> <99435f5b0902050819r41d76670y9ce1c8e478553c43@mail.gmail.com> Message-ID: <20090205101841.59cf6a0a@bugzilla.org> On Thu, 5 Feb 2009 10:19:59 -0600 Bradley Baetz wrote: > What we could have done is to put out an rc, with the promise that the > only difference to the final would be any regression fixes from the > security patch (and the version number bump). I think that would be confusing and difficult, since that would be two release processes, and we don't have any mechanisms in place to have RCs of point releases. > Admins on public > instances could have upgraded and would have been no worse off, while > internal/less critical installations could have waited. In this particular case public instances would have been much worse off--private attachments were accessible with a predictable token when before they were secure. All existing CSRF protection was defeated. Internal installations were always fine. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From bbaetz at acm.org Thu Feb 5 22:18:23 2009 From: bbaetz at acm.org (Bradley Baetz) Date: Thu, 5 Feb 2009 16:18:23 -0600 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <20090205101841.59cf6a0a@bugzilla.org> References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> <20090204152149.2f9e2f48@bugzilla.org> <705f06b0-2245-491d-88ca-7f4c8a7ed911@g39g2000pri.googlegroups.com> <498AC7B0.1020100@bugzilla.org> <99435f5b0902050819r41d76670y9ce1c8e478553c43@mail.gmail.com> <20090205101841.59cf6a0a@bugzilla.org> Message-ID: <99435f5b0902051418i53bb94fbt36a442a1efe82a8@mail.gmail.com> On Thu, Feb 5, 2009 at 12:18 PM, Max Kanat-Alexander wrote: >> What we could have done is to put out an rc, with the promise that the >> only difference to the final would be any regression fixes from the >> security patch (and the version number bump). > I think that would be confusing and difficult, since that would > be two release processes, and we don't have any mechanisms in place to > have RCs of point releases. True, but it'd be less confusing and difficult than releasing another security fix the next day, then another one shortly for any other regression fixes. >> Admins on public >> instances could have upgraded and would have been no worse off, while >> internal/less critical installations could have waited. > > In this particular case public instances would have been much > worse off--private attachments were accessible with a predictable token > when before they were secure. All existing CSRF protection was > defeated. Internal installations were always fine. Well, the token was repeatable not necessarily predictable or usable (the tokens are invalidated after use, so an attacker would have to get in between the request and the redirecct). Not that thats much better.... This particular issue was different to most, both because it was obvious what was changing and because it was very invasive. In general I'm agreeing with your original mail, but where the fix and issue is obvious even without the code, what do we do for the other sites? Bradley From mkanat at bugzilla.org Thu Feb 5 23:55:49 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 5 Feb 2009 15:55:49 -0800 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <99435f5b0902051418i53bb94fbt36a442a1efe82a8@mail.gmail.com> References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> <20090204152149.2f9e2f48@bugzilla.org> <705f06b0-2245-491d-88ca-7f4c8a7ed911@g39g2000pri.googlegroups.com> <498AC7B0.1020100@bugzilla.org> <99435f5b0902050819r41d76670y9ce1c8e478553c43@mail.gmail.com> <20090205101841.59cf6a0a@bugzilla.org> <99435f5b0902051418i53bb94fbt36a442a1efe82a8@mail.gmail.com> Message-ID: <20090205155549.66c26cb0@bugzilla.org> On Thu, 5 Feb 2009 16:18:23 -0600 Bradley Baetz wrote: > True, but it'd be less confusing and difficult than releasing another > security fix the next day, then another one shortly for any other > regression fixes. That's not what I'm proposing. I'm proposing that bmo run the code that will be released before a release is made. > This particular issue was different to most, both because it was > obvious what was changing and because it was very invasive. In general > I'm agreeing with your original mail, but where the fix and issue is > obvious even without the code, what do we do for the other sites? I think 24 hours is a safe period for us to not release the details of the advisory, even if there are operational clues that indicate that there is a security issue. It needs live testing, and this is just the only feasible way. The regressions we've noticed so far weren't found in closed testing, only in live tests. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Fri Feb 6 07:53:49 2009 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 06 Feb 2009 07:53:49 +0000 Subject: Avoiding Future Security Bug Regressions In-Reply-To: References: <20090204142337.5e5986d4@bugzilla.org> <498A2013.9030104@gmail.com> <20090204152149.2f9e2f48@bugzilla.org> <705f06b0-2245-491d-88ca-7f4c8a7ed911@g39g2000pri.googlegroups.com> <498AC7B0.1020100@bugzilla.org> <99435f5b0902050819r41d76670y9ce1c8e478553c43@mail.gmail.com> <20090205101841.59cf6a0a@bugzilla.org> <99435f5b0902051418i53bb94fbt36a442a1efe82a8@mail.gmail.com> Message-ID: Max Kanat-Alexander wrote: > That's not what I'm proposing. I'm proposing that bmo run the > code that will be released before a release is made. While that's a great idea and I hope it happens, I'm not sure it's something within the power of the Bugzilla project to legislate - unless you want to gate releases on b.m.o. upgrades. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From reed at reedloden.com Wed Feb 4 22:43:31 2009 From: reed at reedloden.com (Reed Loden) Date: Wed, 4 Feb 2009 16:43:31 -0600 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <20090204142337.5e5986d4@bugzilla.org> References: <20090204142337.5e5986d4@bugzilla.org> Message-ID: <20090204164331.46f22108.reed@reedloden.com> On Wed, 4 Feb 2009 14:23:37 -0800 Max Kanat-Alexander wrote: > 1) No matter what, no more than one *invasive* security patch > per release. That doesn't make sense at all, imho. If there are critical security bugs that need to get fixed, they should get fixed ASAP and not depend on waiting until some future release. You shouldn't be risking users just because you don't want Bugzilla to look bad that it has to release twice within 24 hours. Security problems, especially with a bug tracking database that contains sensitive testcases, are extremely bad and shouldn't be treated like they can wait indefinitely. If this same policy was applied to Firefox, we'd be releasing a new version multiple times a month, as it's pretty common to have invasive security patches in order to get bugs fixed. While developers do the best they can to make branch patches small and contained, sometimes an invasive patch is necessary. ~reed -- Reed Loden - From mkanat at bugzilla.org Sat Feb 7 05:57:26 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 6 Feb 2009 21:57:26 -0800 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <20090204164331.46f22108.reed@reedloden.com> References: <20090204142337.5e5986d4@bugzilla.org> <20090204164331.46f22108.reed@reedloden.com> Message-ID: <20090206215726.4c051f92@bugzilla.org> On Wed, 4 Feb 2009 16:43:31 -0600 Reed Loden wrote: > If there are critical security > bugs that need to get fixed, they should get fixed ASAP and not depend > on waiting until some future release. I agree, that's why we should release as soon as we have a security patch. We didn't have to fix both issues in one release. > You shouldn't be risking users > just because you don't want Bugzilla to look bad that it has to > release twice within 24 hours. I assume you meant that we shouldn't be putting users at risk, and I understand that, and I agree. We shouldn't be putting users at risk. In this case, we put users far more at risk by releasing multiple invasive patches on a stable branch without any time for live testing. There are other risks than just security risks--risks far more common. The risk of lost productivity, the risk of data loss, the risk of critical bugs that make a product unusable. We shouldn't be placing users at risk of those things, and as we include more invasive patches in one stable release without live testing, those risks dramatically multiply. > If this same policy was applied to Firefox [snip] Although I think that what I said above is enough, and that I do understand what you're saying here, since this has been coming up more and more, I'd like to take this opportunity to point this out: Firefox and Bugzilla are not comparable products. The only thing they have in common is that they are both software, and they are both open-source. Firefox has numerous paid developers, an entire funded organization, and numerous highly involved QA tests and procedures. Firefox has an auto-updater. Bugzilla has zero full-time developers, none of whom are paid in any way. It has exactly two people who spend a significant amount of their time on it (myself and LpSolit), and a small community of additional contributors and active reviewers (who, by the way, are extremely appreciated, and I wish that we had more and more people who contributed and reviewed!). Our IT team essentially consists of me and some time from Mozilla IT that Community Giving is gracious enough to pay for. Our release team currently consists of just me. Although I'd love to have a real funded organization behind Bugzilla, and maybe some day we will, in the present moment we have to adopt policies that work for our environment, and that is an environment of *limited resources*. Having limited resources means that we must accept and understand our limited capabilities, and adapt ourselves in ways that we can still produce a quality product within those constraints. I proposed these policies because they work within those limited constraints, not because I believe they are the best policies any project can adopt. They will work to prevent similar situations as our recent one, in the future, and that is what I am most concerned about. What happened was extremely dangerous, both to our users and to us as a project, and we have to not just handle the dangerous situation (as we did), but also make sure that we adopt firm solutions that will prevent the same situation from recurring in the future. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Sat Feb 7 12:52:30 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sat, 07 Feb 2009 13:52:30 +0100 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <20090206215726.4c051f92@bugzilla.org> References: <20090204142337.5e5986d4@bugzilla.org> <20090204164331.46f22108.reed@reedloden.com> <20090206215726.4c051f92@bugzilla.org> Message-ID: <498D840E.6070903@gmail.com> Le 07. 02. 09 06:57, Max Kanat-Alexander a ?crit : > risk. In this case, we put users far more at risk by releasing multiple > invasive patches on a stable branch without any time for live testing. I agree that invasive patches are more likely to trigger regressions than one-liners (though it's not impossible that a one-liner also breaks something). But I would like to note that it's probably the last time that we will land such invasive patches on branches, because... 1) We are for a few years pretty prompt to fix security issues and crashes when we find them and so to prevent to have 4 branches being affected before starting worrying about them. 2) We are much more focused on security issues and stability problems than in the past, IMO. One reason is the rearchitecture which has been done for a few years which much more easily let us catch possible regressions. Another reason is the creation of the QA team which is able to catch most common problems thanks to their QA tests. As a consequence, patches are rather well tested before landing in CVS. 3) There are no more old security bugs which are here for years and which nobody wanted to fix because they were hard to fix (I probably fixed 80% of the security bugs in these last 4 years myself). I think any new security bug will be related to new features only and so will affect only a small number of branches, which should limit the risk to regress something. LpSolit From mkanat at bugzilla.org Sat Feb 7 19:25:17 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 7 Feb 2009 11:25:17 -0800 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <498D840E.6070903@gmail.com> References: <20090204142337.5e5986d4@bugzilla.org> <20090204164331.46f22108.reed@reedloden.com> <20090206215726.4c051f92@bugzilla.org> <498D840E.6070903@gmail.com> Message-ID: <20090207112517.59ef3de8@bugzilla.org> On Sat, 07 Feb 2009 13:52:30 +0100 "Fr?d?ric Buclin" wrote: > > I agree that invasive patches are more likely to trigger regressions > than one-liners (though it's not impossible that a one-liner also > breaks something). But I would like to note that it's probably the > last time that we will land such invasive patches on branches, > because... [snip] Yeah, I agree with everything you said in that email. They're all very good points. I don't expect to have to do too many invasive security patches in the future. I just wanted to make sure that we have a policy that prevents bad things from happening if we do have to do the invasive patches. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Sun Feb 8 10:58:42 2009 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 08 Feb 2009 11:58:42 +0100 Subject: Avoiding Future Security Bug Regressions In-Reply-To: References: <20090204142337.5e5986d4@bugzilla.org> <20090204164331.46f22108.reed@reedloden.com> Message-ID: Max Kanat-Alexander wrote: > What happened was extremely dangerous, both to our users and > to us as a project, and we have to not just handle the dangerous > situation (as we did), but also make sure that we adopt firm solutions > that will prevent the same situation from recurring in the future. My understanding of what happened would not lead me to use the words "extremely dangerous" - so perhaps I have misunderstood. Why were the particular regressions we had "extremely dangerous"? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From vladd at bugzilla.org Sun Feb 8 14:59:49 2009 From: vladd at bugzilla.org (Vlad Dascalu) Date: Sun, 8 Feb 2009 15:59:49 +0100 Subject: Avoiding Future Security Bug Regressions In-Reply-To: <20090206215726.4c051f92@bugzilla.org> References: <20090204142337.5e5986d4@bugzilla.org> <20090204164331.46f22108.reed@reedloden.com> <20090206215726.4c051f92@bugzilla.org> Message-ID: There are two factors here pushing in opposite ways: (A) -> the speed of getting security bugs fixed / reviewed / commited. (B) -> the speed that BZ installation admins can tolerate in trying out and installing new versions. Firefox has a very fast (B), because: -> it has an auto-updater. -> it's client sofware. Bugzilla has a much slower (B), because: -> it doesn't have an auto-updater. -> it's server software. -> an upgrade impacts the entire organization, not just one user. So while the code HEAD in our version-control system is a great way to iterate, our end-users have a much slower (B) compared to the (B)'s of other MoFo products (Firefox included). You want to avoid regressions by having only one security fix per release. While this would work great in environments where you have a fast (B), I'm afraid it would suck for Bugzilla (for the reasons above). The way to avoid regressions with a slow (B) is to have better QA, not to increase release cycles to a rate which users can't keep up with, especially since we can't vouch for our releases' regressions. On Sat, Feb 7, 2009 at 6:57 AM, Max Kanat-Alexander wrote: > On Wed, 4 Feb 2009 16:43:31 -0600 Reed Loden wrote: > > If there are critical security > > bugs that need to get fixed, they should get fixed ASAP and not depend > > on waiting until some future release. > > I agree, that's why we should release as soon as we have a > security patch. We didn't have to fix both issues in one release. > > > You shouldn't be risking users > > just because you don't want Bugzilla to look bad that it has to > > release twice within 24 hours. > > I assume you meant that we shouldn't be putting users at risk, > and I understand that, and I agree. We shouldn't be putting users at > risk. In this case, we put users far more at risk by releasing multiple > invasive patches on a stable branch without any time for live testing. > > There are other risks than just security risks--risks far more > common. The risk of lost productivity, the risk of data loss, the risk > of critical bugs that make a product unusable. We shouldn't be placing > users at risk of those things, and as we include more invasive patches > in one stable release without live testing, those risks dramatically > multiply. > > > If this same policy was applied to Firefox [snip] > > Although I think that what I said above is enough, and that I > do understand what you're saying here, since this has been coming up > more and more, I'd like to take this opportunity to point this out: > > Firefox and Bugzilla are not comparable products. The only > thing they have in common is that they are both software, and they are > both open-source. Firefox has numerous paid developers, an entire > funded organization, and numerous highly involved QA tests and > procedures. Firefox has an auto-updater. > > Bugzilla has zero full-time developers, none of whom are paid > in any way. It has exactly two people who spend a significant amount of > their time on it (myself and LpSolit), and a small community of > additional contributors and active reviewers (who, by the way, are > extremely appreciated, and I wish that we had more and more people who > contributed and reviewed!). Our IT team essentially consists of me and > some time from Mozilla IT that Community Giving is gracious enough to > pay for. Our release team currently consists of just me. > > Although I'd love to have a real funded organization behind > Bugzilla, and maybe some day we will, in the present moment we have to > adopt policies that work for our environment, and that is an > environment of *limited resources*. Having limited resources means that > we must accept and understand our limited capabilities, and adapt > ourselves in ways that we can still produce a quality product within > those constraints. > > I proposed these policies because they work within those > limited constraints, not because I believe they are the best policies > any project can adopt. They will work to prevent similar situations as > our recent one, in the future, and that is what I am most concerned > about. > > What happened was extremely dangerous, both to our users and > to us as a project, and we have to not just handle the dangerous > situation (as we did), but also make sure that we adopt firm solutions > that will prevent the same situation from recurring in the future. > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Sun Feb 8 19:06:26 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 8 Feb 2009 11:06:26 -0800 Subject: Avoiding Future Security Bug Regressions In-Reply-To: References: <20090204142337.5e5986d4@bugzilla.org> <20090204164331.46f22108.reed@reedloden.com> Message-ID: <20090208110626.638555fa@bugzilla.org> On Sun, 08 Feb 2009 11:58:42 +0100 Gervase Markham wrote: > My understanding of what happened would not lead me to use the words > "extremely dangerous" - so perhaps I have misunderstood. > > Why were the particular regressions we had "extremely dangerous"? They theoretically allowed a persistent-enough attacker to access a private attachment (which on bmo includes security PoCs, as you know) without authorization. (The token was predictable enough [always the same, effectively] that all they had to do was eventually get their request in-between the request and redirect of a real attachment.cgi user--probably easy enough on bmo, with how frequent requests are.) They also defeated all CSRF protection, which is particularly bad after we had publicized the attachment issue. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Mon Feb 9 16:04:26 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 09 Feb 2009 16:04:26 +0000 Subject: Mozilla in the Google Summer of Code 2009 Message-ID: [CCed to all groups who had a category in last year's list. Please respect the Followup-To header.] I can't find an official announcement and there's no 2009 website yet, but I'm pretty sure the Google Summer of Code is running again this year. So, Mozilla community members, please visit the Brainstorming page at: https://wiki.mozilla.org/Community:SummerOfCode09:Brainstorming and, after having read and carefully considered How To Make Good Suggestions, put down ideas for Summer of Code projects. Ideas where you are willing to mentor, or where you have found someone who is, are much more likely to make it to the Approved Ideas page. If last year's timetable is anything to go by, we have about a month before we have to submit our organizational application to take part, and at that point we have to have a well-filled, vibrant ideas list. So please take five minutes to think through what students could usefully do in your area of the project. Thanks! Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From dberlin at dberlin.org Mon Feb 9 16:17:48 2009 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 9 Feb 2009 11:17:48 -0500 Subject: Mozilla in the Google Summer of Code 2009 In-Reply-To: References: Message-ID: <4aca3dc20902090817t3fcb1df4ncd5044e1df3e1166@mail.gmail.com> On Mon, Feb 9, 2009 at 11:04 AM, Gervase Markham wrote: > [CCed to all groups who had a category in last year's list. Please > respect the Followup-To header.] > > I can't find an official announcement and there's no 2009 website yet, > but I'm pretty sure the Google Summer of Code is running again this year. I am happy to confirm it is :) (I am part of Google's open source programs office) --Dan From pablobs at users.sourceforge.net Tue Feb 10 03:08:44 2009 From: pablobs at users.sourceforge.net (Pablo Bender) Date: Tue, 10 Feb 2009 00:08:44 -0300 Subject: How to get "Localized Templates" table updated? Message-ID: Hi, What the procedure to update the contents of "Localized Templates" table in the download page of bugzilla.org? ( http://www.bugzilla.org/download/#localizations ) The pt_BR templates for Bugzilla 3.0 are available on http://bugzilla-br.sourceforge.net/ and the project now is maintened by me - Felipe Gaucho is no longer the maintainer of project. The Table have old values: the pt_BR templates for Bugzilla 2.18 never work fine, 2.17.4 are OK, and the maintainer is not Felipe Gaucho. The correct values for now is: Templates for Bugzilla 3.0, and 2.17.4 and the maintainer is Pablo Bender. We are working for Bugzilla 3.2 templates... but at the moment no release are available. tks Pablo Bender _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From wurblzap at gmail.com Tue Feb 10 14:08:09 2009 From: wurblzap at gmail.com (Marc Schumann) Date: Tue, 10 Feb 2009 15:08:09 +0100 Subject: How to get "Localized Templates" table updated? In-Reply-To: References: Message-ID: Pablo, 2009/2/10 Pablo Bender : > What the procedure to update the contents of "Localized Templates" table > in the download page of bugzilla.org? ( > http://www.bugzilla.org/download/#localizations ) usually, you'd get in touch with somebody on the localization team (see https://wiki.mozilla.org/Bugzilla:L10N). > The pt_BR templates for Bugzilla 3.0 are available on > http://bugzilla-br.sourceforge.net/ and the project now is maintened by > me - Felipe Gaucho is no longer the maintainer of project. The Table > have old values: the pt_BR templates for Bugzilla 2.18 never work fine, > 2.17.4 are OK, and the maintainer is not Felipe Gaucho. > > The correct values for now is: Templates for Bugzilla 3.0, and 2.17.4 > and the maintainer is Pablo Bender. It would be good if you updated https://wiki.mozilla.org/Bugzilla:L10n:Localization_Teams accordingly. As of https://bugzilla.mozilla.org/show_bug.cgi?id=477549, only releases in Bugzilla's supported branches will be shown on the download page, so your release for 3.0 qualifies while 2.17.4 does not. I added pt_BR with the 3.0 release to the list. It'll show up soon. Regards Marc _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From steven.geerts at softathome.com Wed Feb 11 12:23:46 2009 From: steven.geerts at softathome.com (Steven Geerts) Date: Wed, 11 Feb 2009 13:23:46 +0100 Subject: bugzilla 3.3.3 Message-ID: <010501c98c43$95f63d50$c1e2b7f0$@geerts@softathome.com> Hi I just upgraded my 3.2rc1 to version 3.3.3 without any problems but I have some question about the new features. Why are only the custom fields changed so you can have an option to show that field depending on something else. Isn't it also nice to have this on the basic field values. What also can be interesting is, I know the feature request are closed so it's for the next version, that the workflow has group access. Meaning that you can only change to a certain state if you're in a certain group (eg developers can only change the status of the bug to xxxx while admins can really close the bug.) Or maybe it's already in and I don't know how to configure this? Best regards Steven From vipinhegde at gmail.com Wed Feb 11 18:52:27 2009 From: vipinhegde at gmail.com (Vipin hegde) Date: Wed, 11 Feb 2009 10:52:27 -0800 Subject: Self-Introduction: Vipin Hegde Message-ID: <2ed85afa0902111052x7ed585bbqaf91e7692b4c2b1c@mail.gmail.com> Full legal name: Vipin Hegde City, Country: San Jose, USA Web Developer / DBA Hi, I'd like to help out with database-related and general administration tickets. - - Have helped develop numerous web-based, high-traffic sites such as www.loanapp.com, www.bestrate.com; which have numerous CGI and cron-based Perl scripts for their Admin interfaces (even though the consumer-facing parts are built in non-Perl scripting languages) - Have also multi-tasked as MySQL / Oracle / SQL Server DBA in a few companies. I've worked with Perl for the past 8 years, and have been using Bugzilla for almost that long too. I think it's a great tool, and would love the chance to contribute to your efforts in continuing to improve it. -Vipin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Wed Feb 11 19:33:28 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Feb 2009 11:33:28 -0800 Subject: bugzilla 3.3.3 In-Reply-To: <010501c98c43$95f63d50$c1e2b7f0$@geerts@softathome.com> References: <010501c98c43$95f63d50$c1e2b7f0$@geerts@softathome.com> Message-ID: <20090211113328.3713c840@bugzilla.org> On Wed, 11 Feb 2009 13:23:46 +0100 "Steven Geerts" wrote: > Why are only the custom fields changed so you can have an option to > show that field depending on something else. Isn't it also nice to > have this on the basic field values. Because that feature hasn't been implemented yet. > What also can be interesting is, I know the feature request are > closed so it's for the next version, that the workflow has group > access. I'm sure there's already a bug for that. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Feb 11 19:34:30 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Feb 2009 11:34:30 -0800 Subject: Self-Introduction: Vipin Hegde In-Reply-To: <2ed85afa0902111052x7ed585bbqaf91e7692b4c2b1c@mail.gmail.com> References: <2ed85afa0902111052x7ed585bbqaf91e7692b4c2b1c@mail.gmail.com> Message-ID: <20090211113430.619ca419@bugzilla.org> On Wed, 11 Feb 2009 10:52:27 -0800 Vipin hegde wrote: > I'd like to help out with database-related and general administration > tickets. Hey, that's great! You can search for bugs with [PostgreSQL] or [PgSQL] in the title for PostgreSQL bugs, and [Oracle] in the title for Oracle bugs. There's also a [MS-SQL] bug somewhere, about implementing MS-SQL support, although that's a big project, not just a little thing. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From justdave at bugzilla.org Wed Feb 11 21:49:13 2009 From: justdave at bugzilla.org (David Miller) Date: Wed, 11 Feb 2009 13:49:13 -0800 Subject: bugzilla 3.3.3 In-Reply-To: <20090211113328.3713c840@bugzilla.org> References: <010501c98c43$95f63d50$c1e2b7f0$@geerts@softathome.com> <20090211113328.3713c840@bugzilla.org> Message-ID: <499347D9.8060002@bugzilla.org> Max Kanat-Alexander wrote on 2/11/09 11:33 AM: > On Wed, 11 Feb 2009 13:23:46 +0100 "Steven Geerts" > wrote: >> What also can be interesting is, I know the feature request are >> closed so it's for the next version, that the workflow has group >> access. > > I'm sure there's already a bug for that. You could actually do this now by adding some rules to the check_can_change_field sub in Bugzilla/Bug.pm. There's a well-commented section in there explaining where the rules get put and how to structure them. -- 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 guy.pyrzak at gmail.com Wed Feb 11 21:51:20 2009 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Wed, 11 Feb 2009 13:51:20 -0800 Subject: bugzilla 3.3.3 In-Reply-To: <499347D9.8060002@bugzilla.org> References: <20090211113328.3713c840@bugzilla.org> <499347D9.8060002@bugzilla.org> Message-ID: We've started doing some work to make a nice gui on this. I didn't know there was a bug for this. If there is I'll ask our developers to post a patch to it. -Guy On Wed, Feb 11, 2009 at 1:49 PM, David Miller wrote: > Max Kanat-Alexander wrote on 2/11/09 11:33 AM: > >> On Wed, 11 Feb 2009 13:23:46 +0100 "Steven Geerts" >> wrote: >> >>> What also can be interesting is, I know the feature request are >>> closed so it's for the next version, that the workflow has group >>> access. >>> >> >> I'm sure there's already a bug for that. >> > > You could actually do this now by adding some rules to the > check_can_change_field sub in Bugzilla/Bug.pm. There's a well-commented > section in there explaining where the rules get put and how to structure > them. > > -- > Dave Miller http://www.justdave.net/ > System Administrator, Mozilla Corporation http://www.mozilla.com/ > Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ > > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Thu Feb 12 08:27:18 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 12 Feb 2009 00:27:18 -0800 Subject: Feature Freeze for Bugzilla 3.4 Message-ID: <20090212002718.5e6bccb1@bugzilla.org> Bugzilla 3.4 is now feature-frozen. This means that no new enhancements will be accepted for Bugzilla 3.4. Once we have enough pending enhancements for Bugzilla 3.6, we will create a BUGZILLA-3_4-BRANCH and the pending enhancements will be checked in for 3.6. (In other words, the trunk is not frozen, but we won't be branching until there's a good reason to do so.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From sreindl at sreindl.de Wed Feb 25 08:02:07 2009 From: sreindl at sreindl.de (Stephen Reindl) Date: Wed, 25 Feb 2009 09:02:07 +0100 Subject: Problem with hidden fields Message-ID: Hi all, after applying bugzilla trunk to our test installation the following problem pops up: You cannot see or edit the bugs summary and assigned to value. The reason seems to be the change of global.css related to bug https://bugzilla.mozilla.org/show_bug.cgi?id=479197: .bz_default_hidden, .bz_tui_hidden { /* We have !important because we want elements with these classes to always * be hidden, even if there is some CSS that overrides it (we use these * classes inside JavaScript to hide things). */ display: none !important; } This prevents the summary being displayed "!important" does not allow to overwrite a style of an element being modified (i.e. the "display" argument in the style="" area.) Should this bug be reopened? Regards Stephen Reindl -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemma at confuego.org Wed Feb 25 09:05:13 2009 From: lemma at confuego.org (Michael Leupold) Date: Wed, 25 Feb 2009 10:05:13 +0100 Subject: Search.pm SQL queries Message-ID: <200902251005.15059.lemma@confuego.org> Hi, I've recently been scouting around Search.pm, trying to do something about https://bugzilla.mozilla.org/show_bug.cgi?id=476722 (no promises something will come out). I stumbled upon some queries where I'm not entirely sure why they are implemented like that, eg. _commenter: --------------- $$f = "login_name"; $$ff = "profiles.login_name"; $$funcsbykey{",$$t"}($self, %func_args); push(@$supptables, "LEFT JOIN longdescs AS $table " . "ON $table.bug_id = bugs.bug_id $extra " . "AND $table.who IN" . "(SELECT userid FROM profiles WHERE $$term)" ); $$term = "$table.who IS NOT NULL"; --------------- I don't really understand why there's a LEFT JOIN followed by a "who IS NOT NULL" which seems to be the same as an INNER JOIN. Not being a database guru I'm also not sure if the subquery is supposed to perform faster than another join. I think this could be rewritten as: INNER JOIN longdescs AS ld ON ld.bug_id = bugs.bug_id INNER JOIN profiles AS pf ON pf.userid = ld.who AND $$term or even as: INNER JOIN longdescs AS ld ON ld.bug_id = bugs.bug_id INNER JOIN profiles AS pf ON pf.userid = ld.who WHERE $$term (which would provide the best separation and be easiest to work with). It seems that the second and third query perform better (on MySQL 5.1). As I said I'm not an expert on databases so I'd like to get some ideas from people who know more than I do. Regards, Michael From bugreport at peshkin.net Wed Feb 25 13:28:49 2009 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 25 Feb 2009 05:28:49 -0800 Subject: Search.pm SQL queries In-Reply-To: <200902251005.15059.lemma@confuego.org> References: <200902251005.15059.lemma@confuego.org> Message-ID: <49A54791.9090003@peshkin.net> Michael, Boolean charts surround entire WHERE clauses with operators including NOT( ). Add the debug option to some queries where you look for a bug assigned to someone who has never commented and look at the resulting SQL. That said, the logic goes back to MySQL 3 days. There may be opportunities to optimize more with subqueries. -Joel Peshkin Michael Leupold wrote: > Hi, > > I've recently been scouting around Search.pm, trying to do something about > https://bugzilla.mozilla.org/show_bug.cgi?id=476722 (no promises something > will come out). > > I stumbled upon some queries where I'm not entirely sure why they are > implemented like that, eg. _commenter: > --------------- > $$f = "login_name"; > $$ff = "profiles.login_name"; > $$funcsbykey{",$$t"}($self, %func_args); > push(@$supptables, "LEFT JOIN longdescs AS $table " . > "ON $table.bug_id = bugs.bug_id $extra " . > "AND $table.who IN" . > "(SELECT userid FROM profiles WHERE $$term)" > ); > $$term = "$table.who IS NOT NULL"; > --------------- > > I don't really understand why there's a LEFT JOIN followed by a "who IS NOT > NULL" which seems to be the same as an INNER JOIN. Not being a database guru > I'm also not sure if the subquery is supposed to perform faster than another > join. > > I think this could be rewritten as: > INNER JOIN longdescs AS ld ON ld.bug_id = bugs.bug_id INNER JOIN profiles AS > pf ON pf.userid = ld.who AND $$term > > or even as: > INNER JOIN longdescs AS ld ON ld.bug_id = bugs.bug_id INNER JOIN profiles AS > pf ON pf.userid = ld.who WHERE $$term > (which would provide the best separation and be easiest to work with). > > It seems that the second and third query perform better (on MySQL 5.1). > > As I said I'm not an expert on databases so I'd like to get some ideas from > people who know more than I do. > > Regards, > Michael > - > To view or change your list settings, click here: > > From lpsolit at gmail.com Wed Feb 25 13:41:42 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 25 Feb 2009 14:41:42 +0100 Subject: Search.pm SQL queries In-Reply-To: <49A54791.9090003@peshkin.net> References: <200902251005.15059.lemma@confuego.org> <49A54791.9090003@peshkin.net> Message-ID: <49A54A96.40005@gmail.com> Le 25. 02. 09 14:28, Joel Peshkin a ?crit : > That said, the logic goes back to MySQL 3 days. There may be > opportunities to optimize more with subqueries. Joel, we would love if you could contribute again to optimize Search.pm. ;) LpSolit From lemma at confuego.org Wed Feb 25 22:00:05 2009 From: lemma at confuego.org (Michael Leupold) Date: Wed, 25 Feb 2009 23:00:05 +0100 Subject: Search.pm SQL queries In-Reply-To: <49A54791.9090003@peshkin.net> References: <200902251005.15059.lemma@confuego.org> <49A54791.9090003@peshkin.net> Message-ID: <200902252300.08317.lemma@confuego.org> On Wednesday 25 February 2009 14:28:49 Joel Peshkin wrote: > > I've recently been scouting around Search.pm, trying to do something > > about https://bugzilla.mozilla.org/show_bug.cgi?id=476722 (no promises > > something will come out). > > > > I stumbled upon some queries where I'm not entirely sure why they are > > implemented like that, eg. _commenter: > > --------------- > > $$f = "login_name"; > > $$ff = "profiles.login_name"; > > $$funcsbykey{",$$t"}($self, %func_args); > > push(@$supptables, "LEFT JOIN longdescs AS $table " . > > "ON $table.bug_id = bugs.bug_id $extra " . > > "AND $table.who IN" . > > "(SELECT userid FROM profiles WHERE $$term)" > > ); > > $$term = "$table.who IS NOT NULL"; > > --------------- > > > > I don't really understand why there's a LEFT JOIN followed by a "who IS > > NOT NULL" which seems to be the same as an INNER JOIN. Not being a > > database guru I'm also not sure if the subquery is supposed to perform > > faster than another join. > Boolean charts surround entire WHERE clauses with operators including > NOT( ). Add the debug option to some queries where you look for a bug > assigned to someone who has never commented and look at the resulting SQL. > That said, the logic goes back to MySQL 3 days. There may be > opportunities to optimize more with subqueries. Thanks for the pointer. I really didn't consider negation at all. That said it seems the subquery is pretty slow for me. The following seems to run considerably faster while providing the same functionality: LEFT JOIN (longdescs INNER JOIN profiles ON longdescs.who = profiles.userid AND $$term) ON longdescs.bug_id = bugs.bug_id WHERE longdescs.who IS NOT NULL I only tried this on MySQL 5.1 as I don't have a postgres bugzilla database around currently. Unfortunately like this it's still not possible to move the actual query condition $term into a WHERE clause which is what I tried to achieve in the first place. Regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mkanat at bugzilla.org Wed Feb 25 22:06:32 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 25 Feb 2009 14:06:32 -0800 Subject: Search.pm SQL queries In-Reply-To: <200902252300.08317.lemma@confuego.org> References: <200902251005.15059.lemma@confuego.org> <49A54791.9090003@peshkin.net> <200902252300.08317.lemma@confuego.org> Message-ID: <20090225140632.0000c7ef@bugzilla.org> On Wed, 25 Feb 2009 23:00:05 +0100 Michael Leupold wrote: > Unfortunately like this it's still not possible to move the actual > query condition $term into a WHERE clause which is what I tried to > achieve in the first place. Yeah, I wouldn't worry too much about optimization at this point. That would be a separate bug from the one you linked to, anyhow. If we want to move things into the WHERE clause in a way that works with NOT(), we'd have to re-work every function inside Search.pm, I think. It might be possible, but it's something to be careful of and that requires its own bug. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dmarshal at yahoo-inc.com Wed Feb 25 22:40:49 2009 From: dmarshal at yahoo-inc.com (David Marshall) Date: Wed, 25 Feb 2009 14:40:49 -0800 Subject: Search.pm SQL queries In-Reply-To: <200902252300.08317.lemma@confuego.org> Message-ID: There are several areas for improvement with Search.pm. I have fixed some of them for Yahoo!, but because we are so far behind HEAD, I don't have patches to submit yet. (I am working semi-furiously on catching us up and will expose whatever code I can as soon as possible.) This is a lengthy discussion aimed only at Search.pm geeks. You have been warned! Data: We use MySQL 4.1 and have about 2.5M rows in table bugs, about 11M rows in table longdescs. I anecdotally suspect that for at least MySQL 4.1, when the number of possible query plans exceeds some number (around 24), MySQL gives up and just goes with some arbitrary join order, usually the order as written in the query. This means that if Search.pm produces a query such as SELECT (many columns) FROM (many joined tables) WHERE (nasty predicate) the executed query plan will probably suck. For some queries we now do SELECT bugs.bug_id FROM (minimum joined tables) WHERE (nasty predicate) LIMIT 2X followed by SELECT (several columns) FROM (many joined tables) WHERE bugs.bug_id IN (list) LIMIT X We don't use a subquery because if the number of potential bugs is very large, it may cost a lot more to do it this way. Another problem is how confusing the predicate can be - there can be lots of AND/OR/NOT with various paretheses involved. For the biggest improvement we use, that's bad. We convert the charts to a tree of AND/OR nodes, transforming subtrees for negation as needed, combining siblings where possible, and so on. What results is a least complicated predicate, including changing (for instance) "NOT foo IN (1,2,3)" to "foo NOT IN (1,2,3)". That may be a poor example, because the database probably sees those as equivalents. Finally, what has made the biggest difference is based on MySQL 4.1's inability to use multiple indexes at once. Our prime example was to search for bugs where user 123 is either the owner or the QA contact: SELECT (columns) FROM (tables) WHERE (blah) AND (bugs.assignee = 123 OR bugs.qacontact = 123) Disaster! Such queries almost always uses bug_status as an index, which doesn't work very well for us. We rewrite this as (essentially) SELECT (columns) FROM (tables) WHERE (blah) AND bugs.assignee = 'foo' UNION SELECT (columns) FROM (tables) WHERE (blah) AND bugs.qacontact = 'foo' Actually, we do the first query (and assuming it returns some bugs) do the next query as SELECT bugs.bug_id FROM (tables) WHERE (blah) AND bugs.qacontact = 'foo' AND bugs.bug_id NOT IN (list) so that if (blah) is expensive we don't have to pay it for rows we already know are in the result set. Of course, we lock all the tables for these queries to get a consistent view of data. Summary and future direction: Problems with Search.pm have less to do with the transformation of some chart tuple to SQL and more to do with the philosophy on constructing one big query and hoping for the best. Making this more complicated is that for some searches, it is better to just leave things alone and let the database figure it out! I used to say that Search.pm should only return a list of bug IDs that match the search criteria, and then buglist.cgi should get the data needed for display. I'm wavering on that now, because as long as Search.pm has gone to the trouble of figuring everything out, why not just get the data? The future direction of Search.pm for us is to improve the tree mechanism to produce faster queries. This is important for us because our database is growing very quickly. This will probably involve locking all the tables involved and doing possibly multiple queries to determine the list of bugs followed by one grand query to get all the data for those bugs, possibly including stuff in memcached or Sphinx, for instance. On 2/25/09 2:00 PM, "Michael Leupold" wrote: > On Wednesday 25 February 2009 14:28:49 Joel Peshkin wrote: >>> I've recently been scouting around Search.pm, trying to do something >>> about https://bugzilla.mozilla.org/show_bug.cgi?id=476722 (no promises >>> something will come out). >>> >>> I stumbled upon some queries where I'm not entirely sure why they are >>> implemented like that, eg. _commenter: >>> --------------- >>> $$f = "login_name"; >>> $$ff = "profiles.login_name"; >>> $$funcsbykey{",$$t"}($self, %func_args); >>> push(@$supptables, "LEFT JOIN longdescs AS $table " . >>> "ON $table.bug_id = bugs.bug_id $extra " . >>> "AND $table.who IN" . >>> "(SELECT userid FROM profiles WHERE $$term)" >>> ); >>> $$term = "$table.who IS NOT NULL"; >>> --------------- >>> >>> I don't really understand why there's a LEFT JOIN followed by a "who IS >>> NOT NULL" which seems to be the same as an INNER JOIN. Not being a >>> database guru I'm also not sure if the subquery is supposed to perform >>> faster than another join. >> Boolean charts surround entire WHERE clauses with operators including >> NOT( ). Add the debug option to some queries where you look for a bug >> assigned to someone who has never commented and look at the resulting SQL. >> That said, the logic goes back to MySQL 3 days. There may be >> opportunities to optimize more with subqueries. > > Thanks for the pointer. I really didn't consider negation at all. > > That said it seems the subquery is pretty slow for me. The following seems to > run considerably faster while providing the same functionality: > LEFT JOIN (longdescs > INNER JOIN profiles > ON longdescs.who = profiles.userid > AND $$term) > ON longdescs.bug_id = bugs.bug_id > WHERE longdescs.who IS NOT NULL > > I only tried this on MySQL 5.1 as I don't have a postgres bugzilla database > around currently. > Unfortunately like this it's still not possible to move the actual query > condition $term into a WHERE clause which is what I tried to achieve in the > first place. > > Regards, > Michael > From mkanat at bugzilla.org Thu Feb 26 02:56:21 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 25 Feb 2009 18:56:21 -0800 Subject: Search.pm SQL queries In-Reply-To: References: <200902252300.08317.lemma@confuego.org> Message-ID: <20090225185621.1d4474a5@bugzilla.org> On Wed, 25 Feb 2009 14:40:49 -0800 David Marshall wrote: > (I am working semi-furiously on > catching us up and will expose whatever code I can as soon as > possible.) Cool. We refactored Search.pm, so if you gave us a patch right now it wouldn't apply, but the actual internal logic of all the search operators hasn't really changed much, so it shouldn't be too hard to port. > I anecdotally suspect that for at least MySQL 4.1, when the number of > possible query plans exceeds some number (around 24), MySQL gives up > and just goes with some arbitrary join order, usually the order as > written in the query. BTW, this makes me wonder--have you tried an experimental import into PostgreSQL to see if it gives you better query plans/times? I know that Yahoo has a big investment in MySQL and so wouldn't move off it, but I'd be interested to know if there really is a significant difference. I saw a fair difference in some of my testing a few years back, but I didn't have a DB like you guys do. > WHERE bugs.bug_id IN (list) Isn't that IN slow, though? I thought MySQL stopped using indexes on IN clauses over a certain size, or something. > Finally, what has made the biggest difference is based on MySQL 4.1's > inability to use multiple indexes at once. Supposedly fixed in 5.1 or 5.0, though. I'm not sure I've seen any query plans where it actually does that though. > Problems with Search.pm have less to do with the transformation of > some chart tuple to SQL and more to do with the philosophy on > constructing one big query and hoping for the best. Making this more > complicated is that for some searches, it is better to just leave > things alone and let the database figure it out! Yeah, although I'd like to think in an ideal world that the database should always be the best at figuring these things out...or at least that query optimizers will improve in the future. > I used to say that Search.pm should only return a list of bug IDs > that match the search criteria, and then buglist.cgi should get the > data needed for display. I'm wavering on that now, because as long > as Search.pm has gone to the trouble of figuring everything out, why > not just get the data? Yeah, I think eventually Search.pm will just return Bug objects. > The future direction of Search.pm for us is to improve the tree > mechanism to produce faster queries. And perhaps to upgrade to MySQL 5.x and see if that improves things? > This will probably involve locking all the tables involved Probably unnecessary, since 3.2 uses InnoDB? Or you could do READ UNCOMMITTED and see if that makes a difference? > and doing possibly multiple > queries to determine the list of bugs followed by one grand query to > get all the data for those bugs, Yeah, that might be reasonable. I'd want to see what the actual pathological queries are, though, if we're going to adjust things to work better upstream. I'm sure you guys have a lot of data that would be valuable to us in terms of optimization. I'd be opposed to any optimization before we finish refactoring Search.pm architecturally, though, so that should happen first. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lemma at confuego.org Thu Feb 26 09:20:01 2009 From: lemma at confuego.org (Michael Leupold) Date: Thu, 26 Feb 2009 10:20:01 +0100 Subject: Search.pm SQL queries In-Reply-To: <20090225140632.0000c7ef@bugzilla.org> References: <200902251005.15059.lemma@confuego.org> <200902252300.08317.lemma@confuego.org> <20090225140632.0000c7ef@bugzilla.org> Message-ID: <200902261020.11888.lemma@confuego.org> On Wednesday 25 February 2009 23:06:32 Max Kanat-Alexander wrote: > On Wed, 25 Feb 2009 23:00:05 +0100 Michael Leupold > wrote: > > Unfortunately like this it's still not possible to move the actual > > query condition $term into a WHERE clause which is what I tried to > > achieve in the first place. > Yeah, I wouldn't worry too much about optimization at this > point. That would be a separate bug from the one you linked to, anyhow. > If we want to move things into the WHERE clause in a way that works > with NOT(), we'd have to re-work every function inside Search.pm, I > think. It might be possible, but it's something to be careful of and > that requires its own bug. Actually I was just considering what I put into c#1 of that bug (476722). Separating the join and the search term would allow for more generic joins. After looking through all of the search functions this seems fairly unrealistic though. Regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mkanat at bugzilla.org Thu Feb 26 09:36:09 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 26 Feb 2009 01:36:09 -0800 Subject: Search.pm SQL queries In-Reply-To: <200902261020.11888.lemma@confuego.org> References: <200902251005.15059.lemma@confuego.org> <200902252300.08317.lemma@confuego.org> <20090225140632.0000c7ef@bugzilla.org> <200902261020.11888.lemma@confuego.org> Message-ID: <20090226013609.2af9daef@bugzilla.org> On Thu, 26 Feb 2009 10:20:01 +0100 Michael Leupold wrote: > Actually I was just considering what I put into c#1 of that bug > (476722). Separating the join and the search term would allow for > more generic joins. After looking through all of the search functions > this seems fairly unrealistic though. Ahh. Yeah, for now let's not do that. We just want a new way to point to the functions we already have. Then once that's done we can consider additional refactoring. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dmarshal at yahoo-inc.com Thu Feb 26 20:24:18 2009 From: dmarshal at yahoo-inc.com (David Marshall) Date: Thu, 26 Feb 2009 12:24:18 -0800 Subject: Search.pm SQL queries In-Reply-To: <20090225185621.1d4474a5@bugzilla.org> Message-ID: On 2/25/09 6:56 PM, "Max Kanat-Alexander" wrote: > On Wed, 25 Feb 2009 14:40:49 -0800 David Marshall > wrote: >> (I am working semi-furiously on >> catching us up and will expose whatever code I can as soon as >> possible.) > > Cool. We refactored Search.pm, so if you gave us a patch right > now it wouldn't apply, but the actual internal logic of all the search > operators hasn't really changed much, so it shouldn't be too hard to > port. The greater likelihood for this summer is that we'll be able to throw some code out as inspiration for others to make patches, but barring that, I'll eventually produce patches myself. OTOH, every time I have thought, "Cool, I can starting pushing stuff upstream in a few weeks," some new important thing to do shows up and upstream patches move farther back on my calendar. > >> I anecdotally suspect that for at least MySQL 4.1, when the number of >> possible query plans exceeds some number (around 24), MySQL gives up >> and just goes with some arbitrary join order, usually the order as >> written in the query. > > BTW, this makes me wonder--have you tried an experimental > import into PostgreSQL to see if it gives you better query plans/times? > I know that Yahoo has a big investment in MySQL and so wouldn't move > off it, but I'd be interested to know if there really is a significant > difference. I saw a fair difference in some of my testing a few years > back, but I didn't have a DB like you guys do. Too much secret MySQL sauce for this to be a realistic possibility. Oracle would be more likely, but that's not much more realistic. > >> WHERE bugs.bug_id IN (list) > > Isn't that IN slow, though? I thought MySQL stopped using > indexes on IN clauses over a certain size, or something. It could be, but it's probably not going to be any slower than the alternative. I admit that it's probably not the best answer, but it addresses the problem we have now with the technology we have. > >> Finally, what has made the biggest difference is based on MySQL 4.1's >> inability to use multiple indexes at once. > > Supposedly fixed in 5.1 or 5.0, though. I'm not sure I've seen > any query plans where it actually does that though. > >> Problems with Search.pm have less to do with the transformation of >> some chart tuple to SQL and more to do with the philosophy on >> constructing one big query and hoping for the best. Making this more >> complicated is that for some searches, it is better to just leave >> things alone and let the database figure it out! > > Yeah, although I'd like to think in an ideal world that the > database should always be the best at figuring these things out...or at > least that query optimizers will improve in the future. Agreed 100%. The ultimate answer isn't fiddling with the SQL statement - it's having a query optimizer that can do the same thing automagically. I have all kinds of clever ideas (for instance, a Bayesian SQL rewriter that could choose the best SQL for your particular search), but some of those are best reserved for if I ever forget why I don't want to get a PhD. > >> I used to say that Search.pm should only return a list of bug IDs >> that match the search criteria, and then buglist.cgi should get the >> data needed for display. I'm wavering on that now, because as long >> as Search.pm has gone to the trouble of figuring everything out, why >> not just get the data? > > Yeah, I think eventually Search.pm will just return Bug > objects. Generally speaking, this is a good idea. That would add a little bit of cost, but I think it is worth it. > >> The future direction of Search.pm for us is to improve the tree >> mechanism to produce faster queries. > > And perhaps to upgrade to MySQL 5.x and see if that improves > things? We're moving some of our shadow databases to MySQL 5.1 very soon to see what happens. My only concern is whether "improving" queries for 4.1 will actually be counterproductive in 5.1. I see a lot of slow-query log browsing in my future. > >> This will probably involve locking all the tables involved > > Probably unnecessary, since 3.2 uses InnoDB? Or you could do > READ UNCOMMITTED and see if that makes a difference? > >> and doing possibly multiple >> queries to determine the list of bugs followed by one grand query to >> get all the data for those bugs, > > Yeah, that might be reasonable. I'd want to see what the actual > pathological queries are, though, if we're going to adjust things to > work better upstream. I'm sure you guys have a lot of data that would > be valuable to us in terms of optimization. > > I'd be opposed to any optimization before we finish refactoring > Search.pm architecturally, though, so that should happen first. I absolutely agree but wanted to provide some information about what we've learned about Search.pm for folks who are thinking about it now. Effort is better spent, in my opinion, on the refactoring to make it more easily understood and maintained than on having it emit better SQL, at least for those without large databases. > > -Max From bhardwaj.akhil31 at gmail.com Fri Feb 27 06:05:50 2009 From: bhardwaj.akhil31 at gmail.com (Akhil) Date: Thu, 26 Feb 2009 22:05:50 -0800 (PST) Subject: Image magic error in Bugzilla Message-ID: Hi, Please help me in this problem after complete installation of all modules. Its showing error -: Checking perl modules... Checking for CGI.pm (v3.21) ok: found v3.42 Checking for TimeDate (v2.21) ok: found v2.22 Checking for PathTools (v0.84) ok: found v3.12 Checking for DBI (v1.41) ok: found v1.52 Checking for Template-Toolkit (v2.15) ok: found v2.20 Checking for Email-Send (v2.00) ok: found v2.194 Checking for Email-MIME (v1.861) ok: found v1.863 Checking for Email-MIME-Modifier (v1.442) ok: found v1.443 Checking available perl DBD modules... Checking for DBD-Pg (v1.45) ok: found v1.49 Checking for DBD-mysql (v4.00) ok: found v4.010 Checking for DBD-Oracle (v1.19) not found The following Perl modules are optional: Checking for GD (v1.20) ok: found v2.41 Checking for Chart (v1.0) ok: found v2.4.1 Checking for Template-GD (any) ok: found v1.56 Checking for GDTextUtil (any) ok: found v0.86 Checking for GDGraph (any) ok: found v1.44 Checking for XML-Twig (any) ok: found v3.26 Checking for MIME-tools (v5.406) ok: found v5.427 Checking for libwww-perl (any) ok: found v2.033 Checking for PatchReader (v0.9.4) ok: found v0.9.5 Checking for PerlMagick (any) ok: found v6.4.9 Checking for perl-ldap (any) ok: found v0.33 Checking for Authen-SASL (any) ok: found v2.12 Checking for RadiusPerl (any) ok: found v0.13 Checking for SOAP-Lite (any) ok: found v0.710.08 Checking for HTML-Parser (v3.40) ok: found v3.55 Checking for HTML-Scrubber (any) ok: found v0.08 Checking for Email-MIME-Attachment-Stripper (any) ok: found v1.316 Checking for Email-Reply (any) ok: found v1.202 Checking for mod_perl (v1.999022) ok: found v2.000002 &Image::Magick::constant not defined. The required ImageMagick libraries are not installed or not installed properly. END failed--call queue aborted, line 225. Regards Akhil Bhardwaj _______________________________________________ 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 Feb 27 08:40:31 2009 From: justdave at bugzilla.org (David Miller) Date: Fri, 27 Feb 2009 03:40:31 -0500 Subject: Image magic error in Bugzilla In-Reply-To: References: Message-ID: <49A7A6FF.7040107@bugzilla.org> Akhil wrote on 2/27/09 1:05 AM: > Please help me in this problem after complete installation of all > modules. Its showing error -: You're on the wrong newsgroup. You should post this on mozilla.support.bugzilla instead. -- 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 Feb 27 09:32:10 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 27 Feb 2009 01:32:10 -0800 Subject: Search.pm SQL queries In-Reply-To: References: <20090225185621.1d4474a5@bugzilla.org> Message-ID: <20090227013210.2a15b8ab@bugzilla.org> On Thu, 26 Feb 2009 12:24:18 -0800 David Marshall wrote: > The greater likelihood for this summer is that we'll be able to throw > some code out as inspiration for others to make patches, but barring > that, I'll eventually produce patches myself. Cool. Throwing out some code is at least better than nothing. :-) Historically it doesn't have much effect, though. > Too much secret MySQL sauce for this to be a realistic possibility. You mean in the queries you're generating? I was mostly just curious if the query planner does better. > We're moving some of our shadow databases to MySQL 5.1 very soon to > see what happens. My only concern is whether "improving" queries for > 4.1 will actually be counterproductive in 5.1. I see a lot of > slow-query log browsing in my future. Cool! Yeah, that was my concern too--one of the reasons I was curious to know what happens when you guys go to 5.x. > I absolutely agree but wanted to provide some information about what > we've learned about Search.pm for folks who are thinking about it > now. Effort is better spent, in my opinion, on the refactoring to > make it more easily understood and maintained than on having it emit > better SQL, at least for those without large databases. Awesome, I'm glad we agree. I totally appreciate the data about what you've learned, too--it's exactly this sort of information that helps guide our future directions, even in refactoring! :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From jmdesp at alussinan.org Fri Feb 27 10:36:12 2009 From: jmdesp at alussinan.org (Jean-Marc Desperrier) Date: Fri, 27 Feb 2009 11:36:12 +0100 Subject: Image magic error in Bugzilla In-Reply-To: References: Message-ID: David Miller wrote: > Akhil wrote on 2/27/09 1:05 AM: >> Please help me in this problem after complete installation of all >> modules. Its showing error -: > > You're on the wrong newsgroup. You should post this on > mozilla.support.bugzilla instead. OK, so what about turning this into a question that's right for this newsgroup. What about making it a *priority* to remove the Image magic dependence in bugzilla ? - Image magic is probably the most complex component to install in bugzilla. It's not by default in most distribution, and can not be installed only by compiling a perl module. - It's usefulness is incredibly low - I can't help thinking it *must* be possible to replace it with something that causes less problems. At least, a first solution would be to make it really optionnal, and remove it from the list of modules that "install-module.pl --all" installs. Another good thing while talking about "install-module.pl --all" : - it should ask which db you want to use (or except it's name as an option) and only install the components related to it. A last good thing would be to make the installation instruction in Bugzilla-Guide.txt much more streamlined when aiming non-root users using install-module.pl. _______________________________________________ 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 Fri Feb 27 18:29:01 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 27 Feb 2009 19:29:01 +0100 Subject: Image magic error in Bugzilla In-Reply-To: References: Message-ID: <49A830ED.9010405@gmail.com> Le 27. 02. 09 11:36, Jean-Marc Desperrier a ?crit : > What about making it a *priority* to remove the Image magic dependence > in bugzilla ? You are free to not install this package. I never had it installed, and I'm using Bugzilla for years without any problem. This package is optional, not required. LpSolit From bugreport at peshkin.net Fri Feb 27 19:04:45 2009 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 27 Feb 2009 11:04:45 -0800 Subject: Image magic error in Bugzilla In-Reply-To: <49A830ED.9010405@gmail.com> References: <49A830ED.9010405@gmail.com> Message-ID: <49A8394D.8030907@peshkin.net> Fr?d?ric Buclin wrote: > Le 27. 02. 09 11:36, Jean-Marc Desperrier a ?crit : > >> What about making it a *priority* to remove the Image magic dependence >> in bugzilla ? > > You are free to not install this package. I never had it installed, > and I'm using Bugzilla for years without any problem. This package is > optional, not required. > > LpSolit > - From the original post.... Checking for Email-Reply (any) ok: found v1.202 Checking for mod_perl (v1.999022) ok: found v2.000002 &Image::Magick::constant not defined. The required ImageMagick libraries are not installed or not installed properly. ... END failed--call queue aborted, line 225. It looks like it is possible for a system where the Image::Magick module has been incorrectly installed to cause checksetup to croak. While it is true that users should not install CPAN modules without passing their tests, we peobably don't ant bad system to crash checksetup (or other code that use-es the module) without catching the error. From lemma at confuego.org Sat Feb 28 12:04:54 2009 From: lemma at confuego.org (Michael Leupold) Date: Sat, 28 Feb 2009 13:04:54 +0100 Subject: Test for Search.pm Message-ID: <200902281304.57183.lemma@confuego.org> Hi, with all the changes I recently did to Search.pm I figure it is pretty hard to find out if it's still behaving as it did before. As I didn't find any automated test I wanted to ask if you think that's something worth putting some effort into and if you have some ideas on how to construct such a test. Basic idea so far: - Construct an array of input searches and output SQL. - If run, compare the SQL query Search.pm produced for each of the input queries with the stored output SQL in the array. - If the SQL doesn't match, output so the developer can compare and check if searches are equivalent - if they are, replace the static query with the newly created SQL query before committing to make the test work Problems with that: - The SQL produced by Search.pm depends on the database type used - AFAIK Search.pm needs a running database server (so it might not qualify for automatic testing in runtests.pl) Of course you'd have to decide which queries to put into the test to cover as much functionality as possible Regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From ahdevans at gmail.com Sat Feb 28 17:05:43 2009 From: ahdevans at gmail.com (Aaron Evans) Date: Sat, 28 Feb 2009 09:05:43 -0800 Subject: Test for Search.pm In-Reply-To: <200902281304.57183.lemma@confuego.org> References: <200902281304.57183.lemma@confuego.org> Message-ID: <36fce4890902280905l3b855f6dm5695572fe28c78c7@mail.gmail.com> I've got some time and would like to help with this. Do we want selenium tests or unit tests? On Sat, Feb 28, 2009 at 4:04 AM, Michael Leupold wrote: > Hi, > > with all the changes I recently did to Search.pm I figure it is pretty hard > to > find out if it's still behaving as it did before. As I didn't find any > automated test I wanted to ask if you think that's something worth putting > some effort into and if you have some ideas on how to construct such a > test. > > Basic idea so far: > - Construct an array of input searches and output SQL. > - If run, compare the SQL query Search.pm produced for each of the input > queries with the stored output SQL in the array. > - If the SQL doesn't match, output so the developer can compare and check > if > searches are equivalent - if they are, replace the static query with the > newly > created SQL query before committing to make the test work > > Problems with that: > - The SQL produced by Search.pm depends on the database type used > - AFAIK Search.pm needs a running database server (so it might not qualify > for > automatic testing in runtests.pl) > > Of course you'd have to decide which queries to put into the test to cover > as > much functionality as possible > > Regards, > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemma at confuego.org Sat Feb 28 17:46:42 2009 From: lemma at confuego.org (Michael Leupold) Date: Sat, 28 Feb 2009 18:46:42 +0100 Subject: Test for Search.pm In-Reply-To: <36fce4890902280905l3b855f6dm5695572fe28c78c7@mail.gmail.com> References: <200902281304.57183.lemma@confuego.org> <36fce4890902280905l3b855f6dm5695572fe28c78c7@mail.gmail.com> Message-ID: <200902281846.44644.lemma@confuego.org> On Saturday 28 February 2009 18:05:43 Aaron Evans wrote: > > with all the changes I recently did to Search.pm I figure it is pretty > > hard to > > find out if it's still behaving as it did before. As I didn't find any > > automated test I wanted to ask if you think that's something worth > > putting some effort into and if you have some ideas on how to construct > > such a test. > I've got some time and would like to help with this. Do we want selenium > tests or unit tests? I think unit tests would be more appropriate. Looking at buglist.cgi it should be possible to just create Bugzilla::Search objects and get the resulting sql for comparison using Bugzilla::Search::getSQL(). Regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From magic666maker at gmail.com Sat Feb 28 20:27:03 2009 From: magic666maker at gmail.com (magic666maker at gmail.com) Date: Sat, 28 Feb 2009 12:27:03 -0800 (PST) Subject: jpg attacment on new bug Message-ID: I have installed bugzilla on windows server 2003 with IIS 6 Everything is running ok including the mail system Only one thing is bothering me - when a user attach a .jpg picture to new bug I can?t see the attachment ? Is anyone can give me directions to solve this issue?? Thanks _______________________________________________ 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 Feb 28 23:31:57 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 28 Feb 2009 15:31:57 -0800 Subject: jpg attacment on new bug In-Reply-To: References: Message-ID: <20090228153157.57406467@bugzilla.org> On Sat, 28 Feb 2009 12:27:03 -0800 (PST) magic666maker at gmail.com wrote: > I have installed bugzilla on windows server 2003 with IIS 6 > Everything is running ok including the mail system > Only one thing is bothering me - when a user attach a .jpg picture to > new bug I can?t see the attachment ? Hi! The more appropriate place to ask this would be on the support-bugzilla mailing list, described here: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.