[09:47:53] matthiasmullie: hi :-] Are you deploy the "abusefilter emergency shutdown" change you merged roughly an hour ago ? https://gerrit.wikimedia.org/r/#/c/32362/ :) [09:50:36] hashar: will do that right away [09:51:08] matthiasmullie: nice thanks. [13:04:30] New patchset: Hashar; "labs-nagios-builder-pep8 is now voting" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/39694 [13:50:47] New patchset: Hashar; "pep8 for mw/tools/code-utils" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/42760 [13:51:52] New patchset: Hashar; "pep8 on mediawiki/tools/code-utils" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/42761 [13:52:09] New review: Hashar; "job created" [integration/jenkins-job-builder-config] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/42760 [13:52:09] Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/42760 [13:52:31] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/42761 [13:53:54] New patchset: Hashar; "fix repo name for mw/tools/code-utils" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/42762 [13:54:06] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/42762 [13:54:20] New review: Hashar; "typo in Gerrit project name. Fixed with https://gerrit.wikimedia.org/r/#/c/42762/" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/42761 [14:12:31] <^demon> Gerrit's going to be unavailable for just a short bit--rebooting manganese. [14:38:55] ^demon: a candidate for abandon "remove externaledit/externadiff user preference" https://gerrit.wikimedia.org/r/#/c/30173/ ;D [14:39:00] people still use it ! [14:40:52] <^demon> But they shouldn't! [14:47:16] ^demon: I guess we will want to deprecate it after VisualEditor got deployed by showing a warning about removal of that feature "soon" [14:47:24] ^demon: meanwhile I think we should keep it :-] [14:48:00] <^demon> I completely disagree. I think the two features are unrelated. [14:50:00] * aude uses vim as an external editor for my wikipedia .js stuff  [14:50:17] but could imagine people doing that [14:50:21] for syntax highlighting [14:58:06] * anomie just uses the It's All Text Firefox extension to launch vim when necessary [16:49:34] * werdna waves [16:53:52] hi werdna [16:53:54] how are you? [16:53:58] not too bad [16:54:02] settling into my new apartment [16:55:51] oh, where? NL, right? [16:59:00] Maastricht, NL [16:59:59] I wish I were coming to FOSDEM so I could swing by and say hello [17:04:27] yeah, it should be a lot of fun [17:04:31] I'm excited for FOSDEM [17:04:37] always a great conference, I guess you've been before? [17:05:07] no [17:05:15] I have meant to go several times and it has not worked out [17:14:00] AaronSchulz: http://www.mediawiki.org/wiki/Parsoid/RFC:_Longer-term_plan [19:03:06] Echo session for developers starting now in #wikimedia-tech [21:04:38] valeriej: hey, ping -- have you seen test2.wikipedia.org ? [21:06:57] sumanah: Yes! I got familiar with it when I was working on an UploadWizard bug. [21:07:23] cool. valeriej has anyone explained to you why there is a test.wikipedia.org and a test2 as well? [21:07:26] Well, not the whole thing. Just the UploadWizard portion. Ha ha. [21:08:00] sumanah, I must admit that I haven't explained this either yet, because I only have a vague idea. test2 is more bleeding edge? :P [21:08:05] (and hi valeriej!) [21:08:09] okay! I shall explain [21:08:23] * marktraceur doesn't know either, no docs on the subject that I've found [21:08:24] test.wikipedia.org is not set up like the rest of the wikipedia.org or wikimedia.org sites. [21:08:30] (hi andre__!) [21:08:41] marktraceur: it might be on wikitech.wikimedia.org somewhere? the docs? [21:09:06] test.wikipedia.org loads its info DIRECTLY FROM AN NFS FILESYSTEM rather than the way the rest of the cluster is deployed [21:09:12] sumanah: I have before lamented that there is http://wikitech.wikimedia.org/view/Test.wikipedia.org but no counterpart [21:09:12] marktraceur, exactly - if there was a wikipage (maybe there is?) that I could find... :) [21:09:14] (you know, with MySQL & whatnot) [21:09:43] chrismcmahon: ^ sounds like it would help people out to get more docs on this stuff, do you know where there are more docs on what test2.wikipedia.org is and how to deploy to it? maybe in [[How to deploy code]]? [21:10:07] test2, on the other hand, is *just another site on the cluster* and thus is a more lifelike testing place [21:10:12] sumanah: And testwiki is deployed directly from fenari, too (or at least that's what I remember from the deploy I sat in on) [21:10:34] in QA terms it is an "oracle" (an environment that is exactly like the "production" (real user-facing) site [21:10:37] ) [21:10:56] sumanah: That's good to know. I was just testing on both. [21:11:17] so, when our developers need to quickly iterate a fix, they can do that faster on test.wikipedia.org because they can just cp to the filesystem without having to do the "scap" (time-consuming deployment process) [21:11:28] "cp" here being Unixspeak for "copy a file" [21:11:53] But soon, ding-dong the scap will be dead! Or so we hope. [21:12:02] Oh, I see. [21:12:02] but valeriej & andre__, you as testers should basically never test on test.wikipedia.org ..... does that make sense? [21:12:30] yeah, and that's even enough to remember for me :D [21:12:35] you should use test2. [21:13:12] sumanah: Yes, thanks! [21:13:18] And this is why chrismcmahon and robla and I have been saying that EVERY site improvement, every upgrade, every deployment, before it goes to the "real" sites like mediawiki.org and meta and commons and so on, should go to test2.wikipedia.org to be tested first! [21:13:34] Oh hey, someone was awesome: http://wikitech.wikimedia.org/view/Test2.wikipedia.org [21:13:35] and the Wikidata people are following this guideline admirably :-) http://lists.wikimedia.org/pipermail/wikidata-l/2013-January/001550.html valeriej do you know about wikidata? [21:14:18] sumanah: No. [21:14:56] fwiw, test2 is the default target for automated browser tests, with a few exceptions e.g. AFTv5 target is beta labs. [21:15:07] valeriej: https://meta.wikimedia.org/wiki/Wikidata In short: Wikidata provides a way to centrally aggregate lots of *data* that right now is trapped in hard-to-edit, hard-to-search infoboxes on Wikipedia & the sibling sites. [21:15:54] So instead of updating "the population of Pennsylvania" in 8 articles' infoboxes or in some central template that is fiddly to call/use, you can plug into a Wikidata store! [21:16:26] does that make sense valeriej? [21:16:55] sumanah: Yes, thank you. [21:17:08] chrismcmahon: I'm sometimes really lost where I'm expected to test some stuff that's in the making (AFTv5, Echo, etc). So you recommend labs for ArticleFeedbackv5? [21:17:33] (I mean, I know where to find the server configurations and what is installed where. Just the *expectation* where to test.) [21:17:43] andre__: AFTv5 is 100% enabled on beta labs and updated automatically. (although it might break in the future, it's working for now) [21:18:02] valeriej: cool. So, before the end of your internship in late March, you will be seeing more and more Wikidata bugs. [21:18:45] sumanah: Ok, I'll keep an eye out for them. [21:18:46] For instance, on January 14th Wikidata will get integrated into the Hungarian Wikipedia! so Hungarian Wikipedia users will be able to plug into data from wikidata.org [21:19:14] They have their own QA folks at Wikimedia Germany (the Wikimedia chapter that has software developers, QA/managers/etc. working on the Wikidata project) [21:19:31] Just wanted to explain to you (and of course andre__ already knows 95% of this) why that will happen in a week! [21:19:49] chrismcmahon: whenever I hear "betalabs" I still mix up deployment.wikimedia.beta.wmflabs.org and labsconsole.wikimedia.org because both contain "labs". [21:20:14] "betalabs" means "the beta cluster" a.k.a. deployment.wikimedia.beta....... [21:20:42] en.wikipedia.beta.wmflabs.org [21:20:56] sumanah: Oh, yes, I remember reading about that. [21:21:06] sweet [21:21:18] andre__: and if this is even mildly education for you as well that makes me happy :) [21:21:27] sumanah, it is, it is! [21:22:11] yay [21:22:17] chrismcmahon, geez, yet another instance? I think I get lost. If Google's first item for "beta labs wikimedia" would link to that one I'd probably be fine [21:22:19] * andre__ outsourcing his brain to Google [21:23:20] * andre__ bookmarking http://en.wikipedia.beta.wmflabs.org as "Beta labs (the one and only, for real)" [21:24:01] andre__: welllll that's the beta labs *for English Wikipedia* -- arguably the MOST IMPORTANT beta labs site is the one for Commons [21:24:11] or one of the top 5 most important for sure [21:24:36] sumanah: andre__ test2 is the best emulation of commons [21:25:07] chrismcmahon: does it include all the Commons site-specific Gadgets? [21:25:16] sumanah: I think I was never really forced to think of the ambiguity of the term. Now that you say it's kind of clear, yeah. [21:25:52] One reason http://deployment.wikimedia.beta.wmflabs.org/ is probably the better site to bookmark is that it links to those, as a table of contents :-) [21:25:56] your portal to BETANESS [21:26:34] * valeriej renames bookmark to "Portal to BETANESS" [21:27:14] ha [21:27:17] * andre__ gets a smoke, be back in 10min [21:27:21] people will think that is an acronym [21:27:25] * sumanah is half-kidding [21:27:58] valeriej: it might be worth your while to play around with wikidata.org and with test2.wikipedia to see how they interact... [21:28:10] sometime between now and the Hungarian Wikipedia wikidata launch [21:28:21] a suggestion, no obligation [21:28:28] "no salesmen will come to your door" as the ads say [21:28:39] http://lists.wikimedia.org/pipermail/wikidata-l/2013-January/001550.html has more info. [21:29:14] sumanah: Ha ha, will do. Thanks for all the information. [21:30:40] cool [21:31:11] sumanah, andre__: Follow up on Drafts: http://www.mediawiki.org/wiki/User_talk:Trevor_Parscal#Drafts_Extension [21:31:47] rockin' - good work valeriej [21:33:34] andre__: So I assign the bugs back to 'Nobody' (wikibugs-l@lists.wikimedia.org)? [21:35:34] sumanah: Thanks. It feels like one step back, though. [21:36:03] Yeah, assign to Nobody [21:36:12] valeriej: have you heard of "cookie-licking"? [21:36:47] sumanah: No. You're teaching me so much today! [21:36:59] http://communitymgt.wikia.com/wiki/Cookie_Licking [21:37:32] it is a practice humans fall into, like white lies and saying "but I will beat the statistics" [21:38:04] it is a practice to avoid. And clearly stating "this task is now available for anyone to do" -- stopping pretending that an overloaded person will do it -- is an important step [21:39:06] sumanah: I see, thanks. [21:40:08] * bawolff personally would like to do everything [21:40:15] I know it still feels discouraging in one way, but I hope we can make it feel ENcouraging in a different way [21:40:20] you are enabling a future person :-) [21:40:39] Don't worry, I'm well aware I can't do everything [21:41:02] a good example for cookie-licking are all those bug reports that are assigned to a human and set to ASSIGNED state and then that human stopped working on it and forgot to reset the report to NEW state and change the assignee to "nobody", hence others assume that somebody works on it while nothing is happening. [21:41:47] so at some point (long to-do list, hah!) $somebody could go through all those ASSIGNED bug reports where the ASSIGNED state was set over a year ago and ask the assignee: "Hey, still working on this, or not?" [21:41:49] bawolff: oh! I was talking to Valerie. :-) I am glad you are a sensible sort of person (yet still dashing in your own way) [21:42:06] ^demon, Server Error [21:42:06] Missing blob 4c7f60b97c12ec8c3950eaf323e494b9892cc82e [21:42:08] there should be about 100 bug reports in that situation currently IIRC [21:42:15] <^demon> MaxSem: Where? [21:42:21] andre__: how about a script sending a reminder email after a month or so of the asignee not changing the bug. and unassigning it automatically after some more time. [21:42:29] ^demon, https://gerrit.wikimedia.org/r/#/c/42855/ [21:43:02] <^demon> Where did you see that error? [21:43:04] <^demon> Looks fine in the ui to me. [21:43:15] "This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset." [21:43:16] DanielK_WMDE_: hmm, that's like Bugzilla's "whining" concept I guess. Normally people quickly switch it off or set up a filter in the email client to ignore whining emails. At least that's how it was in the last project I worked on. [21:43:19] try rebasing it [21:43:27] andre__: Yeah, I'm about to open up a number of reports. I don't know if the Draft reports are set to assigned, though. [21:43:39] DanielK_WMDE_: why not just a mass-mail from the search results? [21:43:40] <^demon> MaxSem: That's jenkins, not gerrit methinks. [21:43:59] ^demon, if gerrit refuses to rebase it's not jenkins [21:44:00] valeriej: so let's take a look. Are you familiar with the Advanced Query interface in Bugzilla? [21:44:15] * sumanah goes off to do a few other things :-) [21:44:21] andre__: if the interval is fairly large, and automatic unassign relatively soon so the skelletons don't pile too high in the closet, i think it could work [21:44:33] <^demon> Oh, I missed that part. [21:44:36] DanielK_WMDE_, I think I like the idea. [21:45:01] andre__: there should be a warning about automatic unassignment, of course. [21:45:08] <^demon> MaxSem: Do you have the object in your local clone? Try `git show ` [21:45:13] andre__: Is that 'Advanced Search' or something different? [21:45:19] Now if Bugzilla's RPC interface would be slightly better I'd even be more optimistic that it's actually possible via a script... [21:45:40] valeriej, yeah, Advanced Search. It looks scary at first sight but is really powerful: https://bugzilla.wikimedia.org/query.cgi?format=advanced [21:46:26] ^demon, fatal: bad object 4c7f60b97c12ec8c3950eaf323e494b9892cc82e [21:46:55] andre__: Yes, I prefer to search that way. It's just a matter of finding the right component in the right product, usually. :) [21:47:06] <^demon> Bahhhh. [21:47:26] valeriej: so, set Product to "MediaWiki extensions" and Component to "Drafts" and Status to "ASSIGNED". You can use type-ahead in those lists to save some time (e.g. click into the "Component" list and type "Dra"). [21:47:38] <^demon> MaxSem: :( [21:47:43] <^demon> Try a fresh change? [21:47:58] okay, nuking my branch and starting from scratch [21:48:22] valeriej: does it work? [21:48:56] andre__, Bugs Found" I think most of them are 'NEW' or 'REOPENED'. [21:49:03] andre__, "Zarro" [21:49:13] valeriej, yeah, I also get zero results => nothing is in "ASSIGNED state". [21:49:29] valeriej, however we could also check which assignees those open Draft reports have. Do you know how to do that? [21:50:00] (I'd just click "Back" in the browser, or click "Edit Search" at the bottom, to get back to the query.cgi with the previous settings) [21:50:17] andre__: I've pulled the Drafts bugs and it lists the assignee. [21:50:34] valeriej, how do you mean "pulled"? All open? :) [21:51:28] andre__: I don't select a status at all, ha ha. [21:52:02] valeriej, :D Yeah, that also works sometimes. Depends on what you want to query for :P [21:52:25] andre__: Yeah, I was about to say it's probably not the _best_ strategy. [21:52:55] valeriej, I think what I'm after is, when you have a list of bug reports as a result of your query on buglist.cgi, you can click "Change Columns" on the bottom. [21:53:12] There you can add an "Assignee" column (and lots of other things). [21:53:21] and then click "Change Columns". [21:53:35] andre__: Oh, I see it. Yeah, that's good to know. [21:53:46] you can display lots of funny things in buglist.cgi, also keywords and such. But if it's useful highly depends on what you want to do ;) [21:54:19] valeriej, are you in for taking a quick look at the other options on https://bugzilla.wikimedia.org/query.cgi?format=advanced ? [21:54:42] andre__: Sure! [21:56:06] valeriej, so under "Detailed Bug Information" I quite often enter a few words under "Comment", and change the dropdown to "contains the string" if I search for that exact order of words [21:56:35] URL or Whiteboard I don't really use (also because we don't really use the Whiteboard - it's basically a freetext field for tagging without any rules) [21:57:15] andre__: Right. Some bugs have 'testme' under the Whiteboard field. [21:57:39] valeriej, I hope "testme" is in the keyword field instead, because that's also a keyword :) [21:57:51] if you see it in the status whiteboard - it should rather be in the Keywords field. [21:58:07] status whiteboard is for free tagging - you could add anything you want there. [21:58:17] andre__: Oh, ok. [21:58:32] I for example use the whiteboard to sometimes add "aklapper[moreinfo]" on tickets that I should close in a few weeks if there is no response by the reporter [21:58:52] or when retriaging old tickets that have not been touched for ages, and when I don't expect a response. [21:59:28] andre__: Oh, that's good. I have a few of those, but I've just been looking back through bugs I commented on. [22:00:16] Ah nice! You can use any tag you want. So Status Whiteboard really takes *any* words. On the contrary, "Keywords" are more structured as you can only add keywords that actually have been set up in the Bugzilla system. You can get the list of keywords here: https://bugzilla.wikimedia.org/describekeywords.cgi [22:00:33] Keywords can be helpful to narrow down the scope sometimes, but that of course requires knowing the keywords a little bit. The keyword usage is quite good in Wikimedia Bugzilla, so you can expect reports to be properly tagged. [22:00:49] (which I am very happy about, compared to other Bugzillas I use :D) [22:01:47] andre__: Bookmarked, thanks. [22:01:49] so Bugzilla's "primary" organization is via products and components, but you have "categories" that are cross-product/component, and for those you use either keywords to mark them, or ... [22:02:15] ... blocker/tracking bugs. WM Bugzilla has many many of them (and I'm not sure about some if they make sense). [22:02:36] You've probably seen the "Depends on" and "Blocks" fields in a bug report. [22:03:04] The tracking bug for tracking bugs (hell yeah) is https://bugzilla.wikimedia.org/showdependencytree.cgi?id=2007&maxdepth=1&hide_resolved=1 [22:03:46] It's a long list and some existing tracking bugs even have the same purpose as some existing keywords - the things that sometimes happen when projects grow organically. [22:04:20] so for example if there is a bug report that is about an issue with image scaling, you mark that report as blocking bug 41371 [22:04:28] https://bugzilla.wikimedia.org/show_bug.cgi?id=41371 - Thumbnail/imagescaler (tracking) [22:04:49] Theoretically there could also be a "thumbnailing" keyword though - it would serve the same purpose. [22:05:09] andre__: Yeah, I've come across a few. Oh, then I should familiarize myself with those so I can recognize the ones I need to set as a blocker. Got it. [22:05:19] valeriej, you've used depends on / blocks already with the "Drafts" bug, if you remember. [22:05:51] valeriej, I think after a while you see which keywords and blocker bugs are more important or used - forget about the rest I'd say. :P [22:06:33] andre__: Yes, I do. Oh, ha ha, alright. I'll learn as I go. [22:06:55] in case that you've installed my Greasemonkey script there's also a link right to "Show dependency tree / graph" that goes to the list of existing tracking/blocker bugs - as they are simply too many to memorize. [22:07:03] valeriej, same for me - learning as I go :) [22:07:38] Going back to https://bugzilla.wikimedia.org/query.cgi?format=advanced , the Target Milestone (TM), Severity and Priority fields are interesting. [22:07:42] andre__: Yes, it's there. I installed them pretty early on, so I don't know what people usually see on the Bugzilla Interface, ha ha. [22:07:49] ehehe [22:08:01] Rule of thumb: Everything that's colorful is not there by default ;) [22:08:50] When we come closer to a MediaWiki tarball release (like version 1.20.0 that everybody can download and install), regularly taking a look at which open reports should get fixed for that release is good. [22:09:06] In that case you would set "Target Milestone" to "1.20.0" and run the query [22:09:22] (for this example you will find 0 open reports as 1.20.0 is past now, but there are open tickets for 1.21.0 and 1.22.0) [22:09:29] that's more like the part for release management. [22:09:41] andre__: Not usually colorful, got it. Oh, ok. [22:09:51] andre__: what I really miss is a query one can link for "bugs fixed in release 1.x.y." [22:10:43] Nemo_bis, yeah, I can imagine that. There is some stuff on https://toolserver.org/~krinkle/wmfBugZillaPortal/#mediawiki-core but for Project Managers, Bugzilla is a PITA as it doesn't provide any such overviews by default. Other bugtrackers are way better for that. [22:11:07] andre__: mozilla does use such queries though [22:11:22] Nemo_bis, there are some extensions out there though to investigate, plus I'm thinking of putting some queries on the frontpage after having my patch to rewrite it in as the first step, see also bug 22170 [22:11:38] Nemo_bis, but is there a nice project overview page or such? not that I'm aware of [22:12:08] andre__: I don't know, I know that they include such links in thunderbird release notes (IIRC) [22:12:20] Nemo_bis, e.g. GNOME has stuff like https://bugzilla.gnome.org/browse.cgi?product=Evolution [22:12:40] andre__: on your confusion the other day about the [[bugzilla:]] default link, should the interwiki be updated to https://bugzilla.gnome.org/$1 [22:12:43] Nemo_bis, not sure - I guess it's only a query and a stricter policy to set Target Milestones on FIXED bug reports? [22:12:51] andre__: something like that [22:12:57] or yet another field [22:12:57] Nemo_bis, I don't really have a strong opinion on that :) [22:13:02] valeriej: with "Severity" it can be sometimes useful to exclude "enhancement" if you only want "real" bugs and not "Would be nice to also have a kitchen sink included" feature requests [22:13:31] andre__: Yeah, that's true. I've had that problem. [22:13:36] andre__: that would bean that 1) we'd depend on the current rewrite rule, 2) people could link anything with interwikis making syntax as comples as they wish [22:14:00] Nemo_bis, I think I'm really neutral on this, no real opinion, sorry :) [22:14:10] ok :) [22:14:18] not worth doing then ;) [22:14:23] hehe [22:14:25] valeriej: "Search by people" is cool when you want to say "all tickets that I'm CC'ed on" or "all reports I have commented on" [22:15:30] andre__: Yeah, I've saved the search you used for the OPW application to show my initial contribution. [22:15:41] oh true. [22:15:44] If you want all bugs that you have commented on, choose "Search By People > Any of: a Commenter > Contains" and enter %user% or your email address [22:16:08] (there's some funky replacement variables like %user% for your own email address, but I don't know them all by heart) [22:16:56] valeriej, "Search by change history" let's you for example define "give me all tickets where the Status was changed to REOPENED" in the last seven days" [22:17:23] andre__: Thanks, I can help Mitevam with that query she asked about. [22:17:24] valeriej, or also "reports that have not seen any changes for more than one year". Do you have an idea what to set in order to run the latter query? [22:20:57] andre__:...I don't think so. 'Search by Change History' talks about relative dates. Would I use that? [22:21:15] andre__: I have a ponering Bugzilla that's not making me feel so confident about this. [22:21:35] valeriej: yes, give it a try (or just tell me what you would try to enter and where) [22:23:54] andre__: Well 'any change' make me think I would select all of the fields. But I don't know what they would be 'changed to'. (This is under search by change history) [22:24:38] andre__: And the time between 1 year ago and Now. [22:24:45] valeriej, let's not care what changes were made - so any change is fine, don't have anything selected in "where ANY of the fields" [22:25:07] You can also leave "changed to" empty as you didn't choose anything in the first field ("where ANY of the fields") [22:25:32] valeriej, with regard to the time you are close - your query would find all tickets that were changed somehow within the last year, but [22:25:42] I'd love to have those that were NOT changed in the last year [22:25:51] (hence forgotten, rotting reports) [22:26:03] any idea how to do that? :) [22:27:18] andre__: :/ ... So between ___ and 1 year ago? Can I leave that first field blank? [22:27:40] valeriej, perfect, yeah! leave the first one empty, and enter "-1y" in the second one. [22:28:11] you can of course also use "2012-01-08" in this case, but can be helpful to keep it generic to reuse the query [22:29:00] andre__: Oh, '-1y'. Is there a place where they have the relative time notation? Or just 'm' for month 'y' for year 'd' for day. Am I missing any? [22:29:20] I think that's all. maybe also h for hour exists, not sure. There's probably some Bugzilla docs out there :P [22:29:27] but I only use y m and d. [22:29:37] -2h should work though, now that you say. [22:30:20] valeriej: and last but not least on the Query page, "Custom Search" (which was still called "Boolean Search" for a reason a few days ago) lets you create really complicated searches, if everything above didn't suit your needs already, e.g. if you want "Attachment mime type was changed by person X" or such. You can even combine several such queries with AND or OR. [22:30:34] that's really advanced stuff, but yet there is still stuff that you cannot query for unfortunately (e.g. finding the last comment [date and time!] that was made by person X). [22:30:55] So yeah, these are the powers of Bugzilla Search in a nutshell. Hope it wasn't too overwhelming. [22:31:25] I recommend to play with those queries a bit, and if you don't succeed in getting the results that you want please ask :) [22:32:21] andre__: I will. I'll mess with the Change History. I think I need work on that. :P [22:32:44] haha. You can query for a lot of things (and I often wished it would be even more powerful). [22:33:04] valeriej, so I think I'll slowly fade out for today. Happy querying! :) [22:33:22] Oh! So, I'm gonna pull an assignee off of a group of reports for an extension. Do I post a comment as to why I'm doing that, or just do it? [22:34:33] andre__: Thanks, again, for all the new information. [22:34:38] valeriej, do you know how to change several bug reports at once? [22:34:46] if not, let's do that together :) [22:35:07] andre__: No, I don't. Yes, let's. [22:35:46] valeriej, would you share your query first? [22:35:59] I guess it's all open Drafts tickets that are assigned to Tim or so? [22:36:10] andre__, yes. [22:36:34] valeriej, and do you have the buglist.cgi with the results already in front of you? :) [22:36:42] or do we start with the query? [22:37:40] andre__: I just got it. [22:37:57] andre__: The buglist.cgi, that is. [22:38:25] valeriej, how many tickets do you get? [22:39:47] andre__: 38 bugs for Drafts, 34 with Tparscal as assignee. [22:39:57] valeriej, oh perfect, same here [22:40:09] valeriej, at the bottom you see "Change several bugs at once" [22:40:35] after clicking you get the same list, but with checkboxes for each item in the list [22:40:35] andre__: Oh, that's convenient. [22:41:15] andre__: Got it. [22:41:20] valeriej, I'd click the "Check all" button now, and [22:41:42] andre__: Got it. [22:41:47] valeriej, ...you could then just click the " Reset Assignee to default" checkbox. [22:42:09] that might be even more convenient then entering "wikibugs-l@" as the new assignee. And of course leaving everything else as is [22:42:30] valeriej, "Reset Assignee to default" would also work, because https://bugzilla.wikimedia.org/describecomponents.cgi?product=MediaWiki%20extensions lists "Nobody" as default assignee for "Drafts" [22:42:41] andre__: Ok. [22:43:22] * andre__ eagerly awaiting 34 bugmails from valerie in his inbox now :P [22:43:50] Whoops, spammed #mediawiki... [22:43:56] valeriej: btw, before doing masive bug changes you might want to quiet wikibugs bot [22:44:08] Oh damn, I also forget that every time. [22:44:14] (or find someone with the proper rights to do so) [22:44:27] bawolff: Yeah, I'll do that next time. [22:44:43] on the other hand, people should set up filters for their IRC clients, or not set bots into channels that cannot behave ;) [22:45:22] valeriej: don't worry too much. People forget to quiet wikibugs more than half the time they make mass changes [22:46:36] bawolff: Ok. [22:49:50] valeriej, I'll call it a day now. See you tomorrow & enjoy the evening! [22:50:48] andre__: Bye! Thanks! [22:51:00] cheerio :) [22:59:38] Nikerabbit, PHP Warning: Missing argument 3 for SolrTTMServer::createDocument(), called in /usr/local/apache/common-local/php-1.21wmf7/extensions/Translate/ttmserver/SolrTTMServer.php on line 159 and defined in /usr/local/apache/common-local/php-1.21wmf7/extensions/Translate/ttmserver/SolrTTMServer.php on line 179 [23:13:56] New patchset: Catrope; "whitelist Yuri Astrakhan (yurik)" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/42570 [23:14:01] Change merged: Catrope; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/42570 [23:14:51] New review: Hashar; "deployed :)" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/42570