[17:29:45] Krinkle: why remove the AJAX patrolling from AJAX tracking? https://bugzilla.wikimedia.org/show_bug.cgi?id=7851 [17:30:01] see comment on tracker [17:31:12] Krinkle: so we need another tracking bug I guess? [17:31:18] for what? [17:31:36] there is a javascript keyword and a javascript component, I'm not sure what the point of tracking this is. [17:31:42] Anything can use ajax internally, it is part of the web [17:31:59] what keyword? [17:32:19] I did mention the javascript keyword [17:32:54] tracking bug was earlier than keyword and than component [17:33:05] javascript is generic [17:33:18] the purpose of the bug is very simple, "make MediaWiki more AJAXy" [17:33:19] Yes, very generic. Because it is just a language. [17:33:52] yes. and there are devs who are focused only on js or css [17:34:02] Yep, but that can be useful [17:34:09] tracking issues with ajax can be useful, too [17:34:15] I'm not sure it is useful to track issues with anything that *uses* ajax. [17:34:29] * Danny_B|backup is now confused [17:34:37] because being an expert on ajax, is of no use with something that merely uses it. as the bug wouldn't be related *to* ajax. [17:34:52] i thought you were bashing the js tracking bug? [17:34:53] Krinkle: you hijacked a bug making it something totally different [17:34:53] if ajax patrol is broken, knowing ajax is irrelevant. [17:35:02] what js tracking bug? [17:35:04] Nemo_bis: +1 i also told him [17:35:37] Krinkle: i'll tell you and you'll hijack it too :-P [17:35:43] Krinkle: I'll revert your change and create another bug [17:35:49] Nemo_bis: Hold on [17:35:52] Krinkle: 2114 [17:36:04] there is also css tracking bug [17:36:11] Sure, those are find [17:36:12] fine* [17:36:26] i created most of these so people can easier orient [17:36:31] Yes [17:36:38] We're talking about 14123 [17:36:39] such as the ajax tracking bug [17:36:40] !b 14123 [17:36:40] https://bugzilla.wikimedia.org/show_bug.cgi?id=14123 [17:36:58] It can be useful to track issues related to CSS, JavaScript, etc. [17:37:50] There was a bug related to ajax patrolling, the issue was that the i18n brackets on the are shown. [17:38:06] that is completely useless to track under ajax. Just because that feature uses ajax doesn't make it an ajax bug [17:38:33] Krinkle: I added that one only because the AJAX patrolling had that tracking bug as parent [17:38:57] So which change do you disagree with? meta meta talk is useless. [17:39:09] Let's be specific. [17:39:13] Krinkle: then it should have been replaced with (currently nonexisting) component ajax [17:39:34] Danny_B|backup: If you like I can close the tracker and create an AJAX component, sure. [17:39:46] but I think people like trackers for CC functionality [17:40:01] until we have that extension installed to auto-track a component, this is probably better. [17:40:01] see? yo you answered yourself now [17:40:03] +1 to what Danny says [17:40:03] QED [17:40:20] i was using that bug as things-i-might-get-around-to-someday list [17:40:28] I haven't closed the bug. [17:40:47] now it seems to only trakc three other tracking bugs [17:41:00] no, sorry [17:41:04] two tracking and one kinda useless [17:41:26] Nemo_bis: what are you doing? [17:41:35] I asked you specifically to tell me what you disagree with so we can solve it [17:41:41] now you went out and created an even bigger mess [17:41:52] uh, what is https://bugzilla.wikimedia.org/show_bug.cgi?id=43175 ? [17:41:54] MatmaRex: That wasn't me [17:41:56] ah [17:42:19] Krinkle: I already told you but you didn't understand, perhaps showing is easier [17:42:34] you changed the tracking bug in the first place so it's not me doing a mess, sorry [17:42:59] Nemo_bis: actually it's you making a mess right now :/ [17:43:03] Nemo_bis: Tell me, what is the point of tracking issues for components that (internally) use ajax somewhere. "Ajax patrol" uses ajax, but a bug for "The loader image is 404" or "the label is not translated" are not ajax related. [17:43:37] that AJAX (tracking) bug should have probably became JavaScript (tracking) [17:43:51] Krinkle: you keep repeating this but nobody ever proposed using the bug for that [17:43:54] (or merged with https://bugzilla.wikimedia.org/show_bug.cgi?id=2114 ) [17:44:02] Nemo_bis: Yes, you proposed a bug for that. [17:44:08] Krinkle: no [17:44:13] You just re-purposes the ajax tracking bug for exactly that [17:44:20] I fixed it to not become that [17:44:22] because with what was done now, it used to be slightly useful and is no longer :( [17:44:29] MatmaRex: nope. ajaxtrack depends on jstrack [17:44:36] that's how it was originally [17:44:48] Danny_B|backup: krinkle is right in that the AJAX bug didn't really track AJAX issues [17:44:55] or vice versa (i always forget the right way ;-)) [17:45:03] but it shouldn't have been mowed down totally like it was [17:45:17] as, well, people who were CC'd on it were probably CC'd for a reason [17:45:29] They were CCed on it for the issues it originally tracked [17:45:41] MatmaRex: ajaxtrack was started to be "replacement for ajax component" [17:45:44] i was CC'd on it for exactly hwat it was tracking half an hour ago. [17:45:50] what* [17:45:52] Danny_B|backup: Nemo_bis: okay, calm down. Let's create common ground. [17:45:57] "what is the point of tracking issues for components that (internally) use ajax somewhere. "Ajax patrol" uses ajax, but a bug for "The loader image is 404" or "the label is not translated" are not ajax related." [17:46:07] You both agree that*that* is pointless right? [17:46:09] * Danny_B|backup is calm, just a bit frustrated [17:46:21] Krinkle: i agree that this is not AJAX. this is true, but [17:46:36] but it shouldn't have been repurposed, or "restored to the orignalk purpose", or whatnot [17:47:18] Krinkle: I've also fixed that bug now [17:47:22] The bug was for tracking issues with ajax, over time people added all kinds of unrelated junk to it, I removed that junk again. That's all. [17:47:24] right now i don't even know what's happening [17:47:33] can you rather tell me what's the supposed problem? [17:47:36] Nemo_bis: don't change things while they are being discussed :/ [17:47:37] as i was saying at the very beginning - ajaxtrack should have been kept as a replacement for ajax component. and there should have been new bug created "ajax issues tracking" for tracking purely ajax issues [17:47:44] i refresh a page and see totally idfferent content [17:47:44] MatmaRex: I didn't change anything [17:47:56] this solution would satisfy everybody [17:48:01] the bug has been like that for years and we had lost information [17:48:01] Nemo_bis: https://bugzilla.wikimedia.org/show_activity.cgi?id=14123 not at all... [17:48:03] Danny_B|backup: Exactly, that's what I did. I made ajaxtrack to stay as replacement for ajax component. [17:48:34] Krinkle: which bug no? [17:48:49] argh, actually, i don't care, the whole tracking bugs mechanism is shite and i need to create searches whenever i need to find something [17:49:09] * MatmaRex goes to do something useful [17:49:46] shiiit, now i have 30 new bugzilla mails... [17:49:56] Nemo_bis: Danny_B|backup: MatmaRex: One thing at a time. Do we agree that (regardless of what we had, have or are having) we don't need a tracker for issues not related to ajax but merely are for a feature that (somewhere) uses ajax? [17:50:20] e.g. "img 404" or "label not translated" in "ajax patrolling" [17:50:36] Krinkle: I don't disagree, I leave that to you [17:50:45] as you're the one fixing that sort of stuff :p [17:50:48] MatmaRex: when i was taking care about bugzilla in past, i created pretty good tracking system in it. unfortunately none of the paid bugmeisters continued in it so the mess started [17:50:50] (one of those) [17:51:33] Danny_B|backup: Andre seems to be using all the existing tracking bugs a lot (even more than one could ask him), but that seems OT? [17:51:37] Krinkle: i disagree actually. as i said - we need that tracking bug to substitute the component [17:51:52] Danny_B|backup: No, the component you talk about would be to track issues with AJAX [17:51:55] Danny_B|backup: or if you mean replacing components and so you should comment on https://www.mediawiki.org/wiki/Requests_for_comment/Bugzilla_taxonomy [17:52:01] Danny_B|backup: This bug does not subsitute that component. [17:52:12] Krinkle: looking at things once again, i like what Nemo just did, with two different tracking bugs. [17:52:34] Yes, he created a third concept, something nice but irrelevant to what we're discussing. don't let it confuse you [17:53:05] i'm not discussing whatever we were discussing anymore. i like how things currently are. [17:53:23] don't make any revolutional changes again, pretty please. :) [17:53:26] * Danny_B|backup unfortunatelly doesn't have time now to discuss that more and has to leave. frustrated by wasting his (and nemo's) work and unconvinced about the current solution [17:53:54] also, we need a JavaScript component, this is for sure. [17:54:07] MatmaRex: We already have one, and had for a long time now [17:54:30] Nemo_bis: Okay, so "Making MediaWIki more AJAXy" is a subset of "Anything indirectly related to AJAX". That's useful and more defined. [17:54:42] well, in this case we need to kill https://bugzilla.wikimedia.org/show_bug.cgi?id=2114 [17:54:52] But issues against existing components that use ajax are still outside its scope. [17:55:02] MatmaRex: No, because we like CC ability [17:55:02] Krinkle: that's what the bug was since the beginningg, looking at its dependencies, although Danny would expand it further AFAICS [17:55:25] Krinkle: what's the point in having a component and a tracking bug for the same thing? [17:55:27] MatmaRex: And we don't have the bugzilla extension installed yet that allows CC-ing oneself to a component [17:55:44] MatmaRex: It is a selective and ugly workaround for said reason [17:56:00] Krinkle: you can use a feed from a saved search [17:56:07] I use tracking bugs but only because somebody once created them and might have seen a usecase. Personally I consider many of our tracking bugs rather useless. [17:56:11] Nemo_bis, ^ [17:56:26] Krinkle: reasonable mail clients support RSS as well [17:56:29] andre__: Yep, they should mostly be components. [17:56:49] MatmaRex: I already have an RSS reader, but having some CC in E-mail and others in RSS is even worse. [17:57:24] Can we discuss this again once we have a Bugzilla extension installed that allows getting all bugmail for a certain component? Should be in the next eight weeks. ;) [17:57:32] Krinkle: as i said, good mail clients support RSS together with e-mail. Opera does. [17:58:12] MatmaRex: That doesn't matter. They'd be in separate feeds, inboxes whatever. [17:58:30] No point in introducing another workflow. We use e-mail notifications, lots of stuff relies on that. [17:58:52] It's been working fine, it will be fine. We just need to make sure we clean up this duplicate mess between trackers and components [17:59:09] I heared andre__ has his eye on a plugin for bugzilla that makes this even better? [17:59:11] Krinkle: then your client sucks, sorry. code yourself a RSS -> e-mail proxy. :( [17:59:40] I don't use RSS. I don't plan to use RSS. [17:59:54] I'm testing a component watching extension. [17:59:58] MatmaRex: RSS and Mail have dedicated purposes, I know how to properly mix them but don't want to. And definitely most other people will not want to tailer a solution, if we already have it right here! [18:00:05] andre__: that's what I mean, yes. [18:01:24] All will be fine one day! I promise! :P [18:05:34] Okay, done :) Now we have a bug for implementing ajax solutions (bug 14123), and the tracker for issues with the AJAX component itself (bug 43175). [18:05:42] Nemo_bis: Danny_B|backup ^ [18:05:45] thanks [18:06:10] andre__: I know your opinion; as I said, I think it's fair if tracking bugs are maintained only by those who care about them [18:06:29] Then it's also true that some tracking bugs should be components or vice versa, it can be confusing. [18:06:42] (But unrelated.) [18:06:52] Nemo_bis: I re-reverted a few of your reverts that really didn't belong in either interpretation of the bug (not your fault, just other people adding it to "Summary contains *.ajax.*" [18:08:49] Krinkle: seems ok; 14003 perhaps should be re-added? (I've not read it.) [18:09:21] Nemo_bis: Yes, you moved 14003 to 43175, but should've stayed on 14123. [18:09:50] Go ahead. [18:10:52] Krinkle: that's because I blindly assumed you correctly categorised accoding to your definition. :p [18:10:57] (Done.) [18:11:46] Well, I did blindly a categorise according to my definition. I removed everything out of it. But that means removal can be for one of two reasons: 1) Not related to the old definitinon, or 2) Not related to either definition. [18:11:59] s/blindly/correctly [18:12:32] you assumption was correct, but assuming removal of 1) is always the case was wrong. [18:12:35] Anyhow, fixed now. [18:13:33] okay, prepare for disaster. It's Nicholas Cage movie night here. This is going to be good. [18:13:34] cya [18:13:56] cheerio [18:27:16] Nemo_bis: lol, my Gmail started marking bugzilla e-mails as spam now. [18:27:29] i wonder why. [18:27:40] :P [19:45:50] MatmaRex: we got lists.wikimedia.org whitelisted by Google IIRC, maybe andre__ should try to do the same for bugzilla [19:46:15] or maybe the IP bugzilla sends mails from is not included in SPF or something like that? [19:46:35] as long as Gmail marks emails from google-melange.com as spam I don't wonder about anything. [19:46:51] anything that's low level (SPF) is out of my reach anyway. [19:48:24] Nemo_bis: it might have been false alarm, i was poking with my mail client settings at about the same time [19:48:51] i'll watch my spam folder for a few days and poke someone if i notice anything abnormal again [19:54:31] what's your MUA? [23:32:51] andre__: well i can tell you offhand that the first person to talk to about SPF would be jeff_green [23:44:31] gn8 folks