From mkanat at bugzilla.org Wed Sep 1 22:26:08 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 01 Sep 2010 15:26:08 -0700 Subject: The Bugzilla VCS Extension In-Reply-To: <1283291307.3604.19.camel@localhost> References: <4C796A92.6010607@bugzilla.org> <1283291307.3604.19.camel@localhost> Message-ID: <4C7ED300.5070508@bugzilla.org> On 08/31/2010 02:48 PM, Kristis Makris wrote: > Max, can you comment on the relation of this work to the work done by > Scmbug ? Well, as I understand it, Scmbug is a generic interface between any (ideally) bug-tracking system and any (ideally) any version-control system. The VCS extension implements the Bugzilla side of things, and contains a helper for people to implement version-control hooks. Also, we are read-only on the VCS side, currently. I haven't used Scmbug enough to say whether or not the VCS extension will replace it eventually for Bugzilla, though. I suppose you'd be more qualified to answer that. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkgnu at mkgnu.net Fri Sep 3 19:40:55 2010 From: mkgnu at mkgnu.net (Kristis Makris) Date: Fri, 03 Sep 2010 12:40:55 -0700 Subject: The Bugzilla VCS Extension In-Reply-To: <4C7ED300.5070508@bugzilla.org> References: <4C796A92.6010607@bugzilla.org> <1283291307.3604.19.camel@localhost> <4C7ED300.5070508@bugzilla.org> Message-ID: <1283542855.4083.31.camel@localhost> On Wed, 2010-09-01 at 15:26 -0700, Max Kanat-Alexander wrote: > Well, as I understand it, Scmbug is a generic interface between any > (ideally) bug-tracking system and any (ideally) any version-control system. Scmbug looks at the problem from the other direction: it offers intergation of any version control system with any bug-tracking system. The difference is that if some criteria are not met, a version control commit operation is rejected and no information is published in the bug-tracking system. In my understanding, the VCS extension displays anything published in the version control system without means of controlling what is accepted in the version control system. > I haven't used Scmbug enough to say whether or not the VCS extension > will replace it eventually for Bugzilla, though. I suppose you'd be more > qualified to answer that. I am happy to see that it is possible to view in Bugzilla version control information. I would like to understand how this capability can be programmed, and add, if possible, support in Scmbug to publish such VCS information in Bugzilla. In the past, I requested supported in Bugzilla for providing means of general autolinkification, and perhaps the time was right back then. https://bugzilla.mozilla.org/show_bug.cgi?id=314097 Is the VCS capability driven by some data inserted in the database ? Would it be possible then for an external tool, like Scmbug, to be creating such data, synchronously, so that VCS autolinkification can appear in Bugzilla ? -------------- 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 Fri Sep 3 21:35:28 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 03 Sep 2010 14:35:28 -0700 Subject: The Bugzilla VCS Extension In-Reply-To: <1283542855.4083.31.camel@localhost> References: <4C796A92.6010607@bugzilla.org> <1283291307.3604.19.camel@localhost> <4C7ED300.5070508@bugzilla.org> <1283542855.4083.31.camel@localhost> Message-ID: <4C816A20.1040007@bugzilla.org> On 09/03/2010 12:40 PM, Kristis Makris wrote: > In my understanding, the VCS extension displays anything published in > the version control system without means of controlling what is accepted > in the version control system. Right. It's a Bugzilla extension, so it's not interested in controlling what goes on in the VCS. That's what other VCS hooks are for. > I am happy to see that it is possible to view in Bugzilla version > control information. I would like to understand how this capability can > be programmed, and add, if possible, support in Scmbug to publish such > VCS information in Bugzilla. Ah, okay. :-) Look at the "hook.pl" script that's in the VCS extension. It uses the "VCS.add_commit" WebService method. You can tell if the extension is installed by calling the "Bugzilla.extensions" WebService method. > Is the VCS capability driven by some data inserted in the database ? Yep. > Would it be possible then for an external tool, like Scmbug, to be > creating such data, synchronously, so that VCS autolinkification can > appear in Bugzilla ? It would be better to use the WebService method. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gagezuiyrorymvo at gmail.com Sat Sep 4 16:25:33 2010 From: gagezuiyrorymvo at gmail.com (Rory Gage) Date: Sat, 4 Sep 2010 09:25:33 -0700 (PDT) Subject: ADULT FRIENDFINDER Message-ID: <8b5bddaa-e54d-4eae-ab51-e99a00fe2882@k10g2000yqa.googlegroups.com> . Click Here to Enter: >>> http://great-web-online.com/5/adult-friendfinder <<< . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . adult friendfinder adult friendfinders fling adult friendfinder adult friendfinder wikipedia the free encyclopedia friendfinder adult adult friendfinder privacy policy adult friendfinder com affiliate program review adult friendfinder help adult friendfinder subscription rates love oral email adult message friendfinder adult friendfinder messenger connection problems adult friendfinder webcam ip free pass to adult friendfinder adult friendfinder ad michele hallett mnguy197269 adult friendfinder adult friendfinder password adult friendfinder login adult friendfinder com adult friendfinder korea anonymous username adult friendfinder asian adult friendfinder free adult friendfinders videos free adult friendfinder site free adult friendfinder membership free adult friendfinder password adult friendfinder web cams adult personals friendfinder single ads adult friendfinder women largo fl adult friendfinder webcam adult friendfinder winnipeg confirmation show adult friendfinder myspace free adult friendfinder cadastro para parceiros de adult friendfinder adult friendfinder uk adult friendfinder thumbs rating adult friendfinder search adult friendfinder senior adult friendfinder password for adult friendfinder reply email pdt adult friendfinder quejas adult friendfinder stop receiving email adult friendfinder notification who adult friendfinder spread william brown adult friendfinder william eugene brown adult friendfinder swingers adult friendfinder who adult friendfinder who adult friendfinder pics password adult friendfinder is adult friendfinder real john royen adult friendfinder login personals member adult friendfinder friendfinder adults friendfinder and adult dating sites hopewell single women on adult friendfinder login to adult friendfinder matt mcwilliams adult friendfinder mature adult friendfinder message center email adult friendfinder love login to adult friendfinder personalized login to adult friendfinder personalized email login to adult friendfinder personals email adult friendfinder email message love adult friendfinder email missing adult friendfinder fake profiles adult friendfinder crack password adult friendfinder cracks adult friendfinder dating adult friendfinder dating adult friendfinder gold password adult friendfinder hacked password adult friendfinder hacks adult friendfinder fraud adult friendfinder free login adult friendfinder gave out personal adult friendfinder couples adult friendfinder change default search view adult friendfinder chat adult friendfinder chat system adult friendfinder affiliate programs adult friendfinder affiliate signup adult friendfinder ass sweat fetish adult friendfinder cindy largo fl adult friendfinder community adult friendfinder confirmation show myspace adult friendfinder chat system feeds adult friendfinder cindy ewing adult friendfinder cindy ewing svetlovics adult friendfinder hotass 07 adult friendfinder san antonio adult friendfinder search adult friendfinder seattle adult friendfinder privacy polic adult friendfinder profiles adult friendfinder proxy adult friendfinder success stories adult friendfinder tammy himen adult friendfinder tammy himen saskatchewan adult friendfinder services adult friendfinder sexykarol karol sexy adult friendfinder stories adult friendfinder popups adult friendfinder jamaica adult friendfinder largest sex personals world adult friendfinder luckybf adult friendfinder information from answers com adult friendfinder ipo adult friendfinder is commission shaving adult friendfinder no email adult friendfinder open messages standard adult friendfinder passwords adult friendfinder members near salisbury adult friendfinder membership hack adult friendfinder message center . . . . . . . . . . . . . . . . . . . _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Mon Sep 6 17:46:56 2010 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 06 Sep 2010 18:46:56 +0100 Subject: Removing Oracle Support In-Reply-To: References: <4C65F73C.2070009@bugzilla.org> Message-ID: On 17/08/10 02:16, Max Kanat-Alexander wrote: > (b) However, currently, supporting the Oracle database helps Bugzilla, > and we think that decisions like this should be based more on technical > merit than on any sort of political feelings about the situation. Sorry to be late to the party. I don't actually agree agree with that logic; I think it's fine to make technical decisions for political or moral reasons. However, I will also support whatever the project leads decide to do - and that seems to be to retain the driver. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Mon Sep 6 17:53:38 2010 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 06 Sep 2010 18:53:38 +0100 Subject: Try Out Bugzilla's Administrative Features In-Reply-To: References: Message-ID: On 31/08/10 03:20, Max Kanat-Alexander wrote: > It's also linked from the front page of landfill.bugzilla.org. When you > use that system, you can automatically create a fully-populated Bugzilla > installation that you are the administrator of. So now, anybody can try > out the administrative features of Bugzilla without having to ask > anybody or set up anything! That's awesome :-) Does this mean we can use it to create installs to test patches on too, or do we still use the old system for that? Gerv _______________________________________________ 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 Mon Sep 6 21:23:44 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 06 Sep 2010 14:23:44 -0700 Subject: Try Out Bugzilla's Administrative Features In-Reply-To: References: Message-ID: <4C855BE0.2040302@bugzilla.org> On 09/06/2010 10:53 AM, Gervase Markham wrote: > That's awesome :-) Does this mean we can use it to create installs to > test patches on too, or do we still use the old system for that? You should continue to use the old system for that. The Test Installation Creator creates installs owned by a nonexistent user, with random names, that expire after 7 days. So, all of those things wouldn't be appropriate for patch testing. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From alexandercarco at googlemail.com Fri Sep 10 13:11:01 2010 From: alexandercarco at googlemail.com (Mrs Anita Celestine) Date: Fri, 10 Sep 2010 06:11:01 -0700 (PDT) Subject: I found this company selling Original mobile phone at affordable prices and with fast delivery . Message-ID: <13be8f14-fa8a-41a5-b0a8-5db4ee3adb9f@a11g2000vbn.googlegroups.com> I found this company selling Original mobile phone at affordable prices and with fast delivery . Visit Their WEBSITE: www.anitaonlinestoreltd.org in-case anyone is interested kindly view their website and make your order from them and also get the best deal like i did. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From Callek at gmail.com Mon Sep 13 02:11:10 2010 From: Callek at gmail.com (Justin Wood (Callek)) Date: Sun, 12 Sep 2010 22:11:10 -0400 Subject: Removing Oracle Support In-Reply-To: References: <4C65F73C.2070009@bugzilla.org> Message-ID: On 9/6/2010 1:46 PM, Gervase Markham wrote: > On 17/08/10 02:16, Max Kanat-Alexander wrote: >> (b) However, currently, supporting the Oracle database helps Bugzilla, >> and we think that decisions like this should be based more on technical >> merit than on any sort of political feelings about the situation. > > Sorry to be late to the party. > > I don't actually agree agree with that logic; I think it's fine to make > technical decisions for political or moral reasons. > > However, I will also support whatever the project leads decide to do - > and that seems to be to retain the driver. To use a case tangential to bugzilla, but one I agree with. Is the H.264 support-or-not. Which *is* political reasons. And has been expressed as such many times. -- ~Justin Wood (Callek) _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From jacobfox03 at gmail.com Fri Sep 17 20:00:05 2010 From: jacobfox03 at gmail.com (Glyn jones) Date: Fri, 17 Sep 2010 13:00:05 -0700 (PDT) Subject: Canary Wharf Flats Message-ID: <7e10cfe6-fc11-4a34-8797-db70f498d8f1@l32g2000prn.googlegroups.com> If you wanted to have a flat at Canary Wharf then no other real estate company expecting jacobfox.co.uk will suits you. For more information visit us at www.jacobfox.co.uk _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Thu Sep 23 21:00:08 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 23 Sep 2010 14:00:08 -0700 Subject: Make Bugzilla Pretty: A Contest Message-ID: <4C9BBFD8.8060200@bugzilla.org> Hello developers and designers! The time has finally come--we want to make Bugzilla *look nice*! Gone are the days when it is OK for open-source software to be functional but unattractive--we need a UI that not only works well, but also looks great! To this end, we are having a contest for designers, to see who can come up with the best new design for Bugzilla: http://wiki.mozilla.org/Bugzilla:Pretty You don't have to know anything about HTML or Bugzilla (though it helps), you just have to be able to redesign and submit an image to us. With your entry, you could be giving the world a great-looking open-source bug-tracking system, impacting the lives of millions of developers, forwarding the cause of open-source in the new decade, and getting some sweet promotion for yourself in the process! We are looking forward to seeing what you come up with! -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Mon Sep 27 18:02:05 2010 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 27 Sep 2010 19:02:05 +0100 Subject: Invalid statuses in search now ignored rather than honoured? Message-ID: [This issue was found using the BzAPI test suite.] http://some-bugzilla/buglist.cgi?bug_status=Phooey&bug_id=1 In 3.6 and 3.7, this produces Zarro Boogs. In current tip, this produces one bug (bug 1). In other words, bogus bug statuses are no longer being treated as valid, but (I presume) are being validated against the list and the parameter is totally dropped if they do not pass. This leads to the above change of behaviour. Can I ask: is this an intentional change? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From dkl at redhat.com Mon Sep 27 18:53:58 2010 From: dkl at redhat.com (David Lawrence) Date: Mon, 27 Sep 2010 14:53:58 -0400 Subject: Make Bugzilla Pretty: A Contest In-Reply-To: <4C9BBFD8.8060200@bugzilla.org> References: <4C9BBFD8.8060200@bugzilla.org> Message-ID: <4CA0E846.9080809@redhat.com> Something I would also like to see discussed along with this is how to also unclutter the page as well of lesser used fields. I just don't want to see this become a task of just moving fields around until it looks nice. We are adding new custom fields at a pretty good pace and the show_bug.cgi page is just getting bigger and bigger. One thing to think about is maybe doing an approach similar to enter_bug.cgi where you can flag certain fields as "Expert" of "Simple" and then have a way to toggle them on/off from show_bug.cgi. With the new changes to allow fields to be not visible based on product value and other field values which is helpful, we still have some products that need to see most of the custom fields anyway. So hiding by product is not always a solution. One problem with the toggle approach is that although people do not like the page look cluttered they may still want to see that something is set in a field at a quick glance. If the custom advanced field is completely missing from the page view, they may miss some important information. I propose to have the fields marked as "Advanced" to not appear *unless* they contain set data, then appear as a read-only value until the the "Show Advanced Fields" link is clicked. Then the advanced fields would become editable. Another thing discussed in Red Hat is about using user roles to determine which fields are visible/editable. So whether the user is empowered, the assignee, the reporter, etc. certain fields that are not appropriate for them and/or a workflow would just not be visible. Just a thought Dave On 9/23/10 5:00 PM, Max Kanat-Alexander wrote: > Hello developers and designers! The time has finally come--we want to > make Bugzilla *look nice*! Gone are the days when it is OK for > open-source software to be functional but unattractive--we need a UI > that not only works well, but also looks great! > > To this end, we are having a contest for designers, to see who can come > up with the best new design for Bugzilla: > > http://wiki.mozilla.org/Bugzilla:Pretty > > You don't have to know anything about HTML or Bugzilla (though it > helps), you just have to be able to redesign and submit an image to us. > > With your entry, you could be giving the world a great-looking > open-source bug-tracking system, impacting the lives of millions of > developers, forwarding the cause of open-source in the new decade, and > getting some sweet promotion for yourself in the process! > > We are looking forward to seeing what you come up with! > > -Max -- David Lawrence, RHCE dkl at redhat.com ------------------------------------ Red Hat, Inc. Web: www.redhat.com 1801 Varsity Drive Raleigh, NC 27606 What happens when open source way is applied to the world? http://opensource.com From msclrhd at googlemail.com Mon Sep 27 19:02:30 2010 From: msclrhd at googlemail.com (Reece Dunn) Date: Mon, 27 Sep 2010 20:02:30 +0100 Subject: Make Bugzilla Pretty: A Contest In-Reply-To: <4C9BBFD8.8060200@bugzilla.org> References: <4C9BBFD8.8060200@bugzilla.org> Message-ID: On 23 September 2010 22:00, Max Kanat-Alexander wrote: > ? ? ? ?Hello developers and designers! The time has finally come--we want to > make Bugzilla *look nice*! Gone are the days when it is OK for > open-source software to be functional but unattractive--we need a UI > that not only works well, but also looks great! > > ? ? ? ?To this end, we are having a contest for designers, to see who can come > up with the best new design for Bugzilla: > > ? ? ? ?http://wiki.mozilla.org/Bugzilla:Pretty > > ? ? ? ?You don't have to know anything about HTML or Bugzilla (though it > helps), you just have to be able to redesign and submit an image to us. > > ? ? ? ?With your entry, you could be giving the world a great-looking > open-source bug-tracking system, impacting the lives of millions of > developers, forwarding the cause of open-source in the new decade, and > getting some sweet promotion for yourself in the process! > > ? ? ? ?We are looking forward to seeing what you come up with! > > ? ? ? ?-Max Hi, People are free to use the CSS files on http://rhdunn.github.com/web-documents/ -- they are under a Creative Commons Attribution-Share Alike 2.0 UK: England & Wales Licence. minimalist.css -- e.g. http://rhdunn.github.com/web-documents/examples/document.html underwater.css -- e.g. http://rhdunn.github.com/web-documents/examples/document-underwater.html I could look at improving the Bugzilla CSS/styling on top of this. - Reece From after.fallout at gmail.com Mon Sep 27 19:25:00 2010 From: after.fallout at gmail.com (Bill Barry) Date: Mon, 27 Sep 2010 13:25:00 -0600 Subject: Make Bugzilla Pretty: A Contest In-Reply-To: <4CA0E846.9080809@redhat.com> References: <4C9BBFD8.8060200@bugzilla.org> <4CA0E846.9080809@redhat.com> Message-ID: <4CA0EF8C.3030507@gmail.com> David Lawrence wrote: > I propose to have the fields marked as "Advanced" to not appear *unless* > they contain set data, then appear as a read-only value until the the > "Show Advanced Fields" link is clicked. Then the advanced fields would > become editable. Internally here we have discussed having a new preference tab which looks a bit like an edit bug page, but all the fields are mocked up images of themselves. On this page you would hover over a field and 5 options would appear: 1. edit basic 2. read basic (with edit link) / edit advanced 3. read always (with edit link) 3. hidden basic / read advanced (with edit link) 4. hidden always The reasoning for this was that certain fields were entirely unnecessary for certain people. Our thought was we could impersonate users and set their preferences as desired. Ultimately we canceled the project because it was determined that the new aspects of managing Bugzilla would not be worth the benefits. I am not convinced it was a good path to go down anyway. From lpsolit at gmail.com Mon Sep 27 20:51:45 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 27 Sep 2010 22:51:45 +0200 Subject: Make Bugzilla Pretty: A Contest In-Reply-To: <4CA0EF8C.3030507@gmail.com> References: <4C9BBFD8.8060200@bugzilla.org> <4CA0E846.9080809@redhat.com> <4CA0EF8C.3030507@gmail.com> Message-ID: <4CA103E1.1000803@gmail.com> Le 27. 09. 10 21:25, Bill Barry a ?crit : >> I propose to have the fields marked as "Advanced" to not appear *unless* >> they contain set data, then appear as a read-only value until the the >> "Show Advanced Fields" link is clicked. IMO, we don't need a "Show Advanced Fields" link to make fields editable. AFAIK, you can use the onclick event to turn a read-only field into an editable one when you click on it. > Internally here we have discussed having a new preference tab which > looks a bit like an edit bug page, but all the fields are mocked up > images of themselves. On this page you would hover over a field and 5 > options would appear: The problem is that you are moving the complexity elsewhere, and you are still asking your users to know what to do with them. I would tend to say (based on no scientific study) that the reporter and users lambda (typically the ones in the CC list) only care about one thing: when will the bug be fixed? So besides the status+resolution and the target milestone fields, and maybe the priority+severity ones, they are not really interested in the other fields (especially the OS/platform, keywords, URL, status whiteboard, dependency and component ones, + maybe the CC list as such lambda users don't know the other guys in the CC list). They could eventually be interested in already set flags, but in no case in unset flags. All the fields I mentioned as not interesting by the lambda users should be hidden by default, not even as read-only. The "Show Advanced Fields" link that dkl was talking about earlier could the be used to show all hidden fields (maybe as read-only, and using the onclick trick mentioned above). I'm not really worried about advanced users, because 1) they do care about all fields, or almost all of them, and 2) they know which fields can be ignored, and no longer pay attention to them. LpSolit From mkanat at bugzilla.org Mon Sep 27 22:48:07 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 27 Sep 2010 15:48:07 -0700 Subject: Make Bugzilla Pretty: A Contest In-Reply-To: <4CA0E846.9080809@redhat.com> References: <4C9BBFD8.8060200@bugzilla.org> <4CA0E846.9080809@redhat.com> Message-ID: <4CA11F27.2060706@bugzilla.org> On 09/27/2010 11:53 AM, David Lawrence wrote: > Something I would also like to see discussed along with this is how to also > unclutter the page as well of lesser used fields. That's a valid and valuable discussion to have and very possibly a reasonable enhancement to pursue, but it is something that should be viewed as a separate project. We've actually been having this discussion for a long time. Some examples of relevant bugs would be: https://bugzilla.mozilla.org/show_bug.cgi?id=373105 https://bugzilla.mozilla.org/show_bug.cgi?id=415631 https://bugzilla.mozilla.org/show_bug.cgi?id=373418 > We are adding new custom fields at a pretty good pace and the > show_bug.cgi page is just getting bigger and bigger. Honestly, Bugzilla should not have more than four custom fields. In fact, I think that any bug-tracker should not have that many custom fields. So that would be a separate issue from our standard UI. > Another thing discussed in Red Hat is about using user roles to determine > which fields are visible/editable. So whether the user is empowered, the > assignee, the reporter, etc. certain fields that are not appropriate for > them and/or a workflow would just not be visible. This is the tracking bug for changes like that: https://bugzilla.mozilla.org/show_bug.cgi?id=372017 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Mon Sep 27 22:51:46 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 27 Sep 2010 15:51:46 -0700 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: References: Message-ID: <4CA12002.5030503@bugzilla.org> On 09/27/2010 11:02 AM, Gervase Markham wrote: > Can I ask: is this an intentional change? More or less, yes. Here's where it happened: https://bugzilla.mozilla.org/show_bug.cgi?id=535309 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Tue Sep 28 09:26:27 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 28 Sep 2010 10:26:27 +0100 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: References: Message-ID: On 27/09/10 23:51, Max Kanat-Alexander wrote: > On 09/27/2010 11:02 AM, Gervase Markham wrote: >> Can I ask: is this an intentional change? > > More or less, yes. Here's where it happened: > > https://bugzilla.mozilla.org/show_bug.cgi?id=535309 OK. So I think this behaviour makes those fields inconsistent with all the others in terms of their behaviour. In the case of other fields, such as component, platform, op_sys, or custom fields, fieldname=Sproink will not match anything. In the case of these fields for which you have changed the behaviour, status=Sproink will match everything, including things whose status is not Sproink. I think the inconsistency is bad, and that the former behaviour is the preferable one for all fields. Would it be possible to restore it without removing the optimization added in the above bug? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Tue Sep 28 10:06:13 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 28 Sep 2010 11:06:13 +0100 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: References: Message-ID: On 27/09/10 19:02, Gervase Markham wrote: > [This issue was found using the BzAPI test suite.] Here are some other changes in behaviour on the tip which my unit tests have found. Again, it would be helpful to confirm if these are intentional. 1) chfieldfrom/chfieldto date validation 4.0: https://landfill.bugzilla.org/bugzilla-4.0-branch/buglist.cgi?chfieldfrom=2009-Phooey-28&bug_id=1 => '2009-phooey-28' is not a legal date. Tip: https://landfill.bugzilla.org/bugzilla-tip/buglist.cgi?chfieldfrom=2009-Phooey-28&bug_id=1 => One bug found. 2) deadlinefrom/deadlineto date validation The same is true of deadlinefrom and deadlineto. 3) chfieldto problems (I think this one must be a bug...) 4.0: https://landfill.bugzilla.org/bugzilla-4.0-branch/buglist.cgi?chfieldto=2007-07-03&chfield=status_whiteboard&chfieldfrom=2007-07-01&chfieldvalue=nothingafds => One bug found. Tip: https://landfill.bugzilla.org/bugzilla-tip/buglist.cgi?chfieldto=2007-07-03&chfield=status_whiteboard&chfieldfrom=2007-07-01&chfieldvalue=nothingafds => Zarro boogs. This query picks out a change from many years ago, which is identical in the two databases. Removing chfieldto from the second URL shows up the bug (and another one, as it happens). 4) Bugs created before... I want to find all bugs created before 2000-06-17. 4.0: https://landfill.bugzilla.org/bugzilla-4.0-branch/buglist.cgi?chfieldto=2000-06-17&chfield=[Bug%20creation] => 11 bugs found. Tip: https://landfill.bugzilla.org/bugzilla-tip/buglist.cgi?chfieldto=2000-06-17&chfield=[Bug%20creation] => Error: "Can't use [Bug creation] as a field name." 5) owner_idle_time units The value owner_idle_time, available for use in boolean charts, used to be interpreted as days if there was no unit given. It's now interpreted another way, because SqlifyDate() is being used instead of its own custom function. So: 4.0: https://landfill.bugzilla.org/bugzilla-4.0-branch/buglist.cgi?value0-0-0=40000&field0-0-0=owner_idle_time&type0-0-0=greaterthan&bug_id=1 => Zarro boogs found. Tip: https://landfill.bugzilla.org/bugzilla-tip/buglist.cgi?value0-0-0=40000&field0-0-0=owner_idle_time&type0-0-0=greaterthan&bug_id=1 => One bug found. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Tue Sep 28 14:26:24 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 28 Sep 2010 15:26:24 +0100 Subject: Make Bugzilla Pretty: A Contest In-Reply-To: References: <4C9BBFD8.8060200@bugzilla.org> Message-ID: On 27/09/10 19:53, David Lawrence wrote: > We are adding new custom fields at a pretty good pace As the plumber said, "there's your problem, guvnor, right there." http://www.joelonsoftware.com/news/20020912.html > Another thing discussed in Red Hat is about using user roles to determine > which fields are visible/editable. So whether the user is empowered, the > assignee, the reporter, etc. certain fields that are not appropriate for > them and/or a workflow would just not be visible. You can already do this as a fairly non-intrusive customization - just change the templates to check user permissions. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Tue Sep 28 14:27:09 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 28 Sep 2010 15:27:09 +0100 Subject: Make Bugzilla Pretty: A Contest In-Reply-To: References: <4C9BBFD8.8060200@bugzilla.org> Message-ID: On 27/09/10 20:02, Reece Dunn wrote: > People are free to use the CSS files on > http://rhdunn.github.com/web-documents/ -- they are under a Creative > Commons Attribution-Share Alike 2.0 UK: England& Wales Licence. Thank you for your kind offer :-) I would point out, thought, that for the work to become part of Bugzilla, it would need to be under the Mozilla Public Licence (MPL) - http://www.mozilla.org/MPL/ . Gerv _______________________________________________ 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 Sep 28 16:50:28 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 28 Sep 2010 18:50:28 +0200 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: References: Message-ID: <4CA21CD4.2010905@gmail.com> Le 28. 09. 10 11:26, Gervase Markham a ?crit : > OK. So I think this behaviour makes those fields inconsistent with all > the others in terms of their behaviour. You misread the bug. This bug is *fixed*! So the inconsistency should not be present. If this is still reproducible, then I think there is another regression somewhere. LpSolit From lpsolit at gmail.com Tue Sep 28 16:54:35 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 28 Sep 2010 18:54:35 +0200 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: References: Message-ID: <4CA21DCB.2050904@gmail.com> Le 28. 09. 10 12:06, Gervase Markham a ?crit : > Here are some other changes in behaviour on the tip which my unit tests > have found. Again, it would be helpful to confirm if these are intentional. IMO, none of these are intentional, and are probably due to the refactor of Search.pm which happened in Bugzilla 4.2. Maybe when bug_id=NNN is found, it enters some special code which ignores everything else? You should rather file bugs about them, maybe one per issue, so that we can keep track of them. LpSolit From mkanat at bugzilla.org Tue Sep 28 23:16:01 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 28 Sep 2010 16:16:01 -0700 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: References: Message-ID: <4CA27731.7000708@bugzilla.org> On 09/28/2010 03:06 AM, Gervase Markham wrote: > 1) chfieldfrom/chfieldto date validation Definitely intentional. > 2) deadlinefrom/deadlineto date validation Intentional. > Tip: > https://landfill.bugzilla.org/bugzilla-tip/buglist.cgi?chfieldto=2007-07-03&chfield=status_whiteboard&chfieldfrom=2007-07-01&chfieldvalue=nothingafds > > => Zarro boogs. That sounds like a bug. > Tip: > https://landfill.bugzilla.org/bugzilla-tip/buglist.cgi?chfieldto=2000-06-17&chfield=[Bug%20creation] > > > => Error: "Can't use [Bug creation] as a field name." That just means there is some missing or incorrect backwards-compatibility code. That is a bug. > 5) owner_idle_time units > 4.0: > https://landfill.bugzilla.org/bugzilla-4.0-branch/buglist.cgi?value0-0-0=40000&field0-0-0=owner_idle_time&type0-0-0=greaterthan&bug_id=1 > > > => Zarro boogs found. > > Tip: > https://landfill.bugzilla.org/bugzilla-tip/buglist.cgi?value0-0-0=40000&field0-0-0=owner_idle_time&type0-0-0=greaterthan&bug_id=1 > > > => One bug found. That is a behavior change, but not one that I think is bad. It makes owner_idle_time consistent with all of the other time fields. owner_idle_time is (and always has been) broken in various other ways, though, still. If you're curious about known bugs in Search.pm, see the "BROKEN" constants in xt/lib/Bugzilla/Test/Search/Constants.pm. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Tue Sep 28 23:20:10 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 29 Sep 2010 01:20:10 +0200 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: <4CA27731.7000708@bugzilla.org> References: <4CA27731.7000708@bugzilla.org> Message-ID: <4CA2782A.7040301@gmail.com> Le 29. 09. 10 01:16, Max Kanat-Alexander a ?crit : >> 1) chfieldfrom/chfieldto date validation > > Definitely intentional. > >> 2) deadlinefrom/deadlineto date validation > > Intentional. How can this be intentional? If the date is invalid, we should throw an error. What 4.0 does is the correct behavior. From mkanat at bugzilla.org Tue Sep 28 23:23:07 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 28 Sep 2010 16:23:07 -0700 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: <4CA2782A.7040301@gmail.com> References: <4CA27731.7000708@bugzilla.org> <4CA2782A.7040301@gmail.com> Message-ID: <4CA278DB.5000000@bugzilla.org> On 09/28/2010 04:20 PM, Fr?d?ric Buclin wrote: > How can this be intentional? If the date is invalid, we should throw an > error. What 4.0 does is the correct behavior. Oh, I thought that Gerv was saying that the old system *didn't* throw errors and the new one does. You are right, we should most likely throw errors about invalid dates. You're welcome to file bugs about all of these things (although they will probably be caught during refactoring anyhow). -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Wed Sep 29 09:56:48 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 29 Sep 2010 10:56:48 +0100 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: References: <4CA27731.7000708@bugzilla.org> <4CA2782A.7040301@gmail.com> Message-ID: <4CA30D60.6010704@mozilla.org> On 29/09/10 00:23, Max Kanat-Alexander wrote: > You are right, we should most likely throw errors about invalid dates. > You're welcome to file bugs about all of these things (although they > will probably be caught during refactoring anyhow). Thank you for the clarifications. I will to file bugs about all of them. :-) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Sep 29 10:05:09 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 29 Sep 2010 11:05:09 +0100 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: <4CA30D60.6010704@mozilla.org> References: <4CA27731.7000708@bugzilla.org> <4CA2782A.7040301@gmail.com> <4CA30D60.6010704@mozilla.org> Message-ID: On 29/09/10 10:56, Gervase Markham wrote: > Thank you for the clarifications. I will to file bugs about all of them. > :-) ...apart from owner_idle_time. https://bugzilla.mozilla.org/show_bug.cgi?id=600492 https://bugzilla.mozilla.org/show_bug.cgi?id=600494 https://bugzilla.mozilla.org/show_bug.cgi?id=600495 https://bugzilla.mozilla.org/show_bug.cgi?id=600496 Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Sep 29 10:10:11 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 29 Sep 2010 11:10:11 +0100 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: References: Message-ID: On 28/09/10 17:50, Fr?d?ric Buclin wrote: > You misread the bug. This bug is *fixed*! So the inconsistency should > not be present. If this is still reproducible, then I think there is > another regression somewhere. 4.0: https://landfill.bugzilla.org/bugzilla-4.0-branch/buglist.cgi?bug_status=Phooey&bug_id=1 => Zarro boogs. Tip: https://landfill.bugzilla.org/bugzilla-tip/buglist.cgi?bug_status=Phooey&bug_id=1 => One bug found. So, just to be clear: you are agreeing with me that the tip behaviour (which is inconsistent) is broken, and you are also saying that it's a regression? Gerv _______________________________________________ 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 Wed Sep 29 10:26:31 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 29 Sep 2010 12:26:31 +0200 Subject: Invalid statuses in search now ignored rather than honoured? In-Reply-To: References: Message-ID: <4CA31457.6020809@gmail.com> Le 29. 09. 10 12:10, Gervase Markham a ?crit : > So, just to be clear: you are agreeing with me that the tip behaviour > (which is inconsistent) is broken, and you are also saying that it's a > regression? Yes