[09:28:44] 3Bugzilla-Migration: Send two email notifications to active Bugzilla users asking them to join Phabricator - https://phabricator.wikimedia.org/T618#22582 (10Nemo_bis) I realised that the information contained in the second email was sub-optimal. > If you want to receive notifications about bugs you voted, you wi... [10:26:19] 3Phabricator.org: Renaming Phabricator project breaks links (doesn't create redirects) - https://phabricator.wikimedia.org/T910#22600 (10Liuxinyu970226) p:5Volunteer?>3Normal [10:26:24] 3Phabricator.org: Renaming Phabricator project breaks links (doesn't create redirects) - https://phabricator.wikimedia.org/T910#15317 (10Liuxinyu970226) p:5Normal>3Volunteer? [10:28:01] 3Phabricator.org: Renaming Phabricator project breaks links (doesn't create redirects) - https://phabricator.wikimedia.org/T910#15317 (10Liuxinyu970226) [10:36:10] 3Bugzilla-Migration: Send two email notifications to active Bugzilla users asking them to join Phabricator - https://phabricator.wikimedia.org/T618#22614 (10Aklapper) The instructions in T618#18534 above are already linked from https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Bugzilla_data_migrated [12:14:19] 3Bugzilla-Migration: Send two email notifications to active Bugzilla users asking them to join Phabricator - https://phabricator.wikimedia.org/T618#22628 (10Nemo_bis) [12:47:08] 3Phabricator.org: Don't email me on cc changes by default (unless I'm reporter?) - https://phabricator.wikimedia.org/T624#22630 (10He7d3r) [12:59:37] 3Bugzilla-Migration: Bugzilla to Maniphest import script (tracking) - https://phabricator.wikimedia.org/T259#22631 (10Aklapper) [13:01:31] 3Bugzilla-Migration: Default Assigned To lists in Bugzilla must be set up for CC as Herald rules in Phabricator - https://phabricator.wikimedia.org/T496#22635 (10Aklapper) [13:04:50] 3Bugzilla-Migration: Create projects for Pywikibot's compat and core versions, and assign the corresponding tasks to each - https://phabricator.wikimedia.org/T1282#22636 (10Aklapper) >>! In T1282#22399, @Aklapper wrote: > The current names of the Version field in Bugzilla are "compat (1.0)" and "core (2.0)". > P... [13:29:26] 3Bugzilla-Migration: Create projects for Pywikibot's compat and core versions, and assign the corresponding tasks to each - https://phabricator.wikimedia.org/T1282#22637 (10valhallasw) I'd suggest to just drop the numbers and use 'core' and 'compat'. Renaming them in BZ sounds reasonable. [13:46:13] 3RT-Migration: Set up redirects from RT URLs to Phabricator - https://phabricator.wikimedia.org/T41#22638 (10Aklapper) >>! In T41#14112, @Dzahn wrote: > magnesium already has php5-cli, php5-mysql, libapache2-mod-php5 sounds to me like we are likely covered already. > any other requirements your script has? if y... [13:50:37] 3Bugzilla-Migration: Restrict Bugzilla access to read-only - https://phabricator.wikimedia.org/T1234#22642 (10Aklapper) [13:54:18] 3Bugzilla-Migration: Add "converted to Phabricator Task NNNN" comment to old-bugzilla bug during migration - https://phabricator.wikimedia.org/T934#22644 (10Aklapper) >>! In T934#16029, @Qgil wrote: > I assume the Bugzilla banner doesn't take dynamic parameters, right? Nope. :( > In order to check the Phabri... [13:57:36] 3Phabricator.org: Email signature is included in task description - https://phabricator.wikimedia.org/T866#22646 (10Aklapper) >>! In T866#16716, @Jaredzimmerman-WMF wrote: > Would it be possible to copy paste our email signature into our phabricator profile to add it to a blacklist? Currently not, and I would r... [14:43:02] 3Project-Management: Make sure anti-vandalism features are up to snuff - https://phabricator.wikimedia.org/T84#22654 (10Qgil) [15:03:48] 3Project-Management: Make sure anti-vandalism features are up to snuff - https://phabricator.wikimedia.org/T84#22662 (10Qgil) p:5Low>3Normal [15:29:51] 3Bugzilla-Migration: Create projects for Pywikibot's compat and core versions, and assign the corresponding tasks to each - https://phabricator.wikimedia.org/T1282#22667 (10Qgil) a:5Qgil>3Aklapper Tag projects created: #pywikibot-core & #pywikibot-compat Renaming versions already in Bugzilla makes total sen... [15:46:42] 3Project-Management: Phabricator lacks a "notification" feed similar other project management software: Enable "Flame" - https://phabricator.wikimedia.org/T1047#22673 (10Qgil) >>! In T1047#18244, @chasemp wrote: > I feel comfortable doing this if someone can make a wiki portion about why "notification server not... [15:51:03] 3Code-Review, Phabricator.org: Arcanist installer for Windows - https://phabricator.wikimedia.org/T172#22674 (10Qgil) [16:02:22] 3Project-Management, Phabricator.org: Show project description(s) on "Create New Task" page - https://phabricator.wikimedia.org/T1277#22675 (10Qgil) >>! In T1277#22470, @Mattflaschen wrote: > This task could be as simple as a tooltip. It might be worth filing a task upstream proposing a tooltip for project labe... [16:07:04] qgil: everything should be filed upstream [16:07:21] qgil: as they typically don't accept patches without corresponding bug [16:07:30] qgil: which I learned the hard way... [16:08:00] hi valhallasw`cloud they are three maintainers; I recommend to file upstream only those requests that are either very important or very close to a potential implementation [16:08:18] I would add there is a difference between wikimedia has filed this upstream and needs it [16:08:31] and someone associated with wikimedia thinks this one thing can personally be improved [16:08:38] and we should be very judicious about the first [16:08:42] as I said, anything we want *must* be filed upstream before someone from us takes up the task [16:08:46] and teh second is not really relevant [16:09:07] we have plenty of requests in https://phabricator.wikimedia.org/tag/phabricator.org/ and filing all of them just would "devaluate" the tasks that matter most. This is what I mean. [16:09:19] qgil: except that not filing them also means no-one can work on them [16:09:56] unless WMF changes the stance 'we don't want to maintain local patches' [16:10:12] honestly we need to go through our "wikimedia" tasks upstream and route most of them to low or wishlist [16:10:21] and make anything normal and above actual WMF needed features [16:10:34] valhallasw`cloud, your comment comes from https://phabricator.wikimedia.org/T1277#22675 , right? [16:10:37] and maybe we could communicate to upstream that we have a large umbrella of tasks not all of which are officially needed [16:11:09] I was just saying to Matt that such little piece might make sense in the minds of the upstream maintainers (tooltips for project labels, just like tasks have tooltips too) [16:11:26] have to go now, but see https://secure.phabricator.com/D10858 [16:11:30] will be back in ~60 mins [16:11:31] chasemp, on the cleaning upsttream, agreed [16:11:48] valhallasw`cloud, let's talk when you're back. I saw it. [16:11:57] qgil: bugzilla preview...I need those resources back this week [16:12:02] I can take back that instance? [16:12:15] I could throw up a page w/ content on what / why / who [16:12:35] I'm at my limit on labs resources [16:12:37] chasemp, do you really need *that* instance? [16:13:08] is this a hard limit> [16:13:09] ? [16:13:34] I think there are ways to get resources allocated but I don't know what the deal is exactly [16:13:40] I mean... this is the last week we will need bugzillapreview, but I think it would be good not to touch it [16:13:43] it would cost me half a day at best to move things over to somwhere else [16:13:52] idk technically that project is archived [16:13:59] so what is the official point of it now? [16:14:27] how hard is it to increase your Labs usage limit? [16:14:34] that I can ask [16:15:05] chances of people asking at some point this week "so how would XYZ look like" are high [16:15:17] I have been showing examples based on bugzillaprevew every other day [16:15:30] I mean, if there is no other choice... [16:15:44] I'm asking neither andrew nor coren seem about yet [16:16:19] ok [16:20:59] coren is about, I think I'm alright on space [16:21:11] I'll leave that instance alone if I possibly can [16:22:41] qgil: ^ [16:23:59] chasemp, thank you! [16:24:02] ^d now that we have a few repo's working for real, thoughts on having viewable to all? [16:25:33] chasemp, I'm not sure about doing this right now. I a few weeks we will have plenty more users familiar with the Phabricator UI with only Maniphest [16:26:01] now everything will be new for most, and if we can save them the Diffusion part (and the why repo XYZ is not here?) [16:26:04] I'm not saying advertise it [16:26:07] but we are getting things like https://phabricator.wikimedia.org/T1291#22676 [16:26:15] where it's going to be MORE confusing for people [16:26:26] who don't get taht it's in some kind of quasi-pilot phase [16:26:28] chasemp, having it in the left menu is to advertise it. [16:26:58] ok fair if that's how you feel then we should probably either yank it [16:27:00] or open it up [16:27:03] <^d> Morning folks. Talking about same thing I was thinking about. [16:27:16] I vote open it up, it's really simple ui wise to me [16:27:22] I can't figure out the disadvantage I guess [16:28:04] when I say advertise I mean, we aren't proposing it as gitblit alt yet but if you find it useful it is there [16:28:55] chasemp, you are not representative of what will be the average Phabricator user starting next week [16:29:10] agreed [16:29:15] the only hard and fast I know is [16:29:27] people are linking to something we have limited to small group of users in a non-obvious way [16:29:32] I'd say, there s enough to digest jumping from Bugzilla to Phabricator [16:29:34] that's not improving useability [16:29:40] ok then we should yank it [16:29:52] <^d> ugh, I'd +1 to opening it up. [16:30:10] I'd say there are two natural situations: [16:30:31] 1. No Diffusion, there is enough novelty with Phabricator + Maniphest only [16:30:49] 2. Diffusion is here. Find your preferred repo, all of them are here. [16:31:21] Opening Diffusion with onlya few repos a few das before migrating Bugzilla sounds... risky [16:31:33] how? [16:31:37] <^d> I disagree. I don't think we're going to have *all* the repos for quite some time. [16:31:43] Whoever is looking at those tasks with permissions restricted kind of know what is going on [16:31:45] I agree with ^d [16:32:08] if you think it's too much for a bugzilla person to understand then ok we yank it [16:32:12] then go ahead, this is one of those things where I wish I am wrong [16:32:16] I disagree and think it's making too much of it [16:32:21] well, this is exactly what I think [16:32:47] as said, go for tit [16:32:51] it [16:33:00] well it's weird to say you don't want to do it, and then to say do it [16:33:09] I mean you are on the hook the most for bz user experience [16:33:14] I would go w/ your judgement [16:33:16] i just disagree with it [16:33:35] because I won't pick a fight for this with chasemp and d^ , and you feel quite sure about it [16:34:15] oh man no fight picking here I'm not at all upset [16:34:49] your call in my mind but I have to make the case I think is strongest [16:35:33] I just want to say: you both are sure about this, I'm not. I don't have arguments to convince you. You can go ahead. Worst case scenario: we pull it. [16:36:15] being as there is no official diffusion status I guess we pull it, ^d? [16:36:59] chasemp, for some reasons my words are not transmitting what I want to say [16:37:11] proposal: let's talk in our team meeting in a few hours? [16:37:25] sure, I'm not trying to obtuse I just don't want to do it if you aren't comfortable with it [16:37:42] convincing you to be on board in one thing, doing it over objections is another [16:37:54] same here :) [16:37:55] this is really no big deal I think either way [16:38:21] but it's a nice feature to have and quickly shows how phab dominates over bz for someone who "gets it" [16:39:10] <^d> I'll just shut this thing off. Already wasted too many cycles discussing it. [16:39:19] thanks [16:39:21] The question is, how many will get it, and how many will be more confused. Think that the Bugzilla migration alone will bring an unknown deal of confusion on its own [16:40:18] <^d> Can Use Application Administrators [16:40:19] <^d> Default View Policy Administrators [16:42:36] This discussion wasn't fair for anybody... [17:09:31] 3Code-Review: Enable Diffusion in phabricator.wikimedia.org for everybody - https://phabricator.wikimedia.org/T1294 (10Qgil) 3NEW p:3Normal [17:10:32] 3Code-Review: Enable Diffusion in phabricator.wikimedia.org for everybody - https://phabricator.wikimedia.org/T1294#22687 (10Qgil) [17:12:01] 3Code-Review: Enable Diffusion in phabricator.wikimedia.org for everybody - https://phabricator.wikimedia.org/T1294#22700 (10Jdforrester-WMF) I'd recommend enabling now; it's already been hugely useful in kicking of the discussion (bikeshedding?) about repo naming, and having the commit merges and task comments... [18:00:45] qgil: *waves* [18:02:08] qgil: basically, my point is the following. We don't want to maintain our own phabricator tree, so patches have to be merged upstream. We need to get upstreams opinion on that, even on trivial matters, as they won't merge patches that don't fall within their plan for phab. [18:02:52] and that's true even for patches that seem like a completely reasonable idea, as can be seen by my default avatar patch [18:07:20] 3Bugzilla-Migration: Create projects for Pywikibot's compat and core versions, and assign the corresponding tasks to each - https://phabricator.wikimedia.org/T1282#22715 (10Legoktm) Can we not TitleCase "PyWikiBot"? It's just "Pywikibot" :) [18:08:05] 3Bugzilla-Migration: Unrecoverable Fatal Error on uploading certain .ico files in Phabricator - https://phabricator.wikimedia.org/T1296 (10Aklapper) 3NEW p:3High [18:08:22] 3Bugzilla-Migration: Unrecoverable Fatal Error on uploading certain .ico files in Phabricator - https://phabricator.wikimedia.org/T1296#22717 (10Aklapper) [18:15:40] valhallasw`cloud: I prefer to not flood upstream with *all* our requests in their Phab instance. I'd rather ask on IRC if an idea makes sense and if code would get accepted in upstream. If they are not against it, one can create a ticket in upstream Phab. [18:16:14] andre__: that's just an informal way of doing the same, without registering that it has happened [18:16:29] yeah, but it's wasting less attention of less people. [18:16:48] but I see pro's and con's, true. [18:17:35] that's a sane line of thought valhallasw`cloud man, no doubt, I think the addendum would be the maintaining our own local stuff is not on the table _for the moment_. So anything we upstream should be something we feel like we can't live without until phab is assigned some development resources post migration [18:18:01] andre__: nonsense. It takes as much time from the phab team, it takes maybe slightly more effort for whoever is thinking of migrating the bug (because that person has to login to secure.phabricator.o instead of irc) and it saves hours for whoever tries to implement it and gets rejected [18:18:04] otherwise good ideas like a better default icon it seems like are candidates for a local issue and then waiting [18:19:02] basically, every bug that's on our phab marked as 'phabricator(.org)' but not on s.phab.o should have a huge warning saying 'do not even think of working on this' [18:19:29] makes sense to "pending local maintainers" tag? [18:19:30] idk [18:19:43] I see the frustration but there is also only so many people and resources available [18:20:07] chasemp: I honestly don't see how it costs more time to file a bug at s.phab.o than to ask the phab team on irc [18:20:11] * YuviPanda fondly remembers times of 'uh, so we have this bugzilla install and we have modified a bit of the checked out code and we do not know' [18:20:28] it doesn't I think, the idea that that flooding upstream with requests from "wikimedia" [18:20:41] when there are genuie things we NEED is unhelpful and not respectful of their time [18:20:46] so filing it upstream as you ok by me [18:20:56] filing it upstream and tagging wikimedia is not really good use of our clout [18:21:02] and they have been super nice about everything [18:21:11] We're not asking *them* to implement it, we're asking for their opinion [18:21:20] I don't see how that's unhelpful and not respectful of their time [18:21:21] opinions are time and money [18:21:33] Yes, but they explicitly say they *want* to give their opinion. [18:22:16] where? [18:22:48] https://secure.phabricator.com/book/phabcontrib/article/contributing_code/ [18:23:08] The most important parts of contributing code to Phabricator are: [18:23:08] 1) File a task with a bug report or feature request before you write code. [18:23:08] 2) ... [18:23:14] sure [18:23:18] just don't tag it with wikimedia [18:23:23] if it's not a wikimedia needs it thing [18:23:37] 3Bugzilla-Migration: Unrecoverable Fatal Error on uploading certain .ico files in Phabricator - https://phabricator.wikimedia.org/T1296#22731 (10Aklapper) Potentially affected: * [[ https://bugzilla.wikimedia.org/buglist.cgi?f1=attachments.mimetype&o1=equals&query_format=advanced&v1=image%2Fx-icon | 9 Bugzilla t... [18:24:03] what chasemp just said probably makes the most sense, true. [18:25:02] upstream is seeing a lot of bikeshedding and issue logging and we are trying to keep the really necessary wikimedia stuff very clear [18:25:05] stuff like this https://secure.phabricator.com/T6531#83719 [18:25:28] and there is more from btrahan to that guy where they go through all the issues they are logging etc [18:26:16] there's this field called 'priority'.... [18:26:20] our presence in upstream is pretty noticeable, to request for comment on every issue that every person in any fashion wants comment on and have them all be equally critical in the eyes of upstream is what I mean when I say not respectful of their time [18:27:00] the people doing the migration are asking you nicely not to log issues upstream if we as a group locally haven't agreed we want to ask for upstreams time on them officially [18:27:10] you can choose to respect it or not that's your all [18:27:12] call even [18:27:34] chasemp: yes, and I'm asking for the team to respect volunteer's time, and you're clearly not interested in doing that. [18:28:05] so I'll find something else to play with instead. [18:28:07] I don't feel that way or want to give that impression in the least, why are you opposed to not adding the wikimedia tag to things you personally want? [18:28:31] chasemp: the problem is having the bugs in OUR phabricator gives the impression patches are welcome [18:28:58] I understand that, but I don't knwo what the best thing to do about it is [18:28:59] with people even saying things such as 'upstream is probably interested in this' [18:29:35] the ambigiouity of the phab.org tag is real in my mind as well [18:29:35] so shall I edit the project description of the "phabricator.org" project? [18:29:59] "not clear what's going to happen here and if patches are welcome either downstream and/or upstream"? [18:30:11] * andre__ needs better wording though [18:30:12] well...can we limit that tag to things we have logged upstream? [18:30:19] and make a phab enhancement tag? [18:30:27] logged upstream is a column on the board of that project [18:30:28] enhancements could be status unknown here or there [18:30:28] currently [18:30:31] yes, except that anyone can add tags, and it's clear for no-one what tag is for what [18:30:33] upstream issues should all be logged upstream [18:31:10] and 'phab enhancement' still suggests work on it is welcome [18:31:15] I guess we really need to sort out how many code changes we want to and can maintain downstream. Rather sooner than later. And that's management stuff. [18:31:26] <^d> chasemp: Heh, we have a user on BZ like aik099 :) [18:31:38] the main problem is that their process is completely different from what people expect from WMF engineering [18:31:41] <^d> He shows up about 2-3 times a year to file a pile of bugs that get INVALID/WONTFIX :) [18:32:16] I see tagging something as an enhancement [18:32:18] with phab tag [18:32:36] as a good alt to having thing in phab.org that aren't meant to be upstreamed yet from wikimedia as a group [18:32:51] but if that's still confusing I'm not sure what a better work around is [18:34:06] chasemp: possibly splitting the upstream tag into wikimedia-musthave and wikimedia-ideas, or something like that. [18:34:21] although filing as not-wikimedia also works [18:34:25] but someone has to do that [18:35:09] My intention is that upstream tasks get heavy cleanup [18:35:22] and some version of real blockers being normal and this type of thing being wishlist happens [18:35:40] and can become consistent, but short of that filing things in wikimedia project upstream is confusing for them on our priorities [18:35:41] hmm, maybe just add a workboard at the phabricator.org with 'Not filed upstream. Tasks must be filed upstream before being worked on' ? [18:35:52] the #phabricator.org tag [18:36:16] afaik that exists for this reason [18:36:17] https://phabricator.wikimedia.org/project/board/6/ [18:36:36] i.e. I thought needs discussion there was not meant to be upstreamed yet [18:36:42] but I'm not sure how true to that things are atm [18:37:14] maybe big disclaimers and such in the project description would mitigate this so it's not frustrating for people who want to help [18:37:20] chasemp: again, *everything* someone could reasonably work on *should* be upstreamed [18:37:58] sure, chicken / egg we need to clean up our upstream queue to communicate priorities before that makes practical sense [18:38:20] also, there's the complete confusion on 'phabricator' vs 'phabricator.org' [18:39:27] yes I have no real opinion on it, that's hwo andre and quim I think have found it useful to track this sort of thing [18:40:32] I admit that some request do make a lot of sense, but I sometimes also just move random stuff there like "but I don't like this color" because there's more important things to deal with currently... so we/I need to retriage that stuff soon. [18:40:46] (refering to items under the "phab.org" project) [18:41:07] "phabricator" is stuff to tackle in our instance only. [18:41:24] if the project descriptions aren't clear and don't help distinguish, we should fix them. [18:41:27] *if*. [18:42:00] I think "upstreamed" combined with "phabricator" would maybe be best for things upstreamed? [18:42:09] that also makes it generic for any local project we are tracking [18:42:10] idk [18:42:24] it's all compromises on clarity for fresh eyes vs tired ones [18:43:44] 3Bugzilla-Migration: Create projects for Pywikibot's compat and core versions, and assign the corresponding tasks to each - https://phabricator.wikimedia.org/T1282#22732 (10Qgil) [18:52:14] * qgil reads back [18:56:54] valhallasw`cloud, chasemp andre__ I agree #phabricator.org needs organization and cleanup. Same for #Wikimedia upstream. We need more discipline in both, for the benefit of everybody. [18:59:18] valhallasw`cloud, upstream has some rules for processing requests and handle code contributions. We should adapt to them, and most of times we are doing it. [18:59:29] I will start cleaning #Wikimedia upstream. [19:19:08] 3Phabricator.org: We need a Wikimedia process for filing tasks and patches upstream in the name of Wikimedia - https://phabricator.wikimedia.org/T1298#22735 (10Qgil) [19:22:37] 3Phabricator.org: We need a Wikimedia process for filing tasks and patches upstream in the name of Wikimedia - https://phabricator.wikimedia.org/T1298 (10chasemp) [19:56:25] 3Bugzilla-Migration: Apply patch to fix Bugzilla XML-RPC API issue before importing comments, remove it before importing attachments - https://phabricator.wikimedia.org/T815#22745 (10Dzahn) https://gerrit.wikimedia.org/r/#/c/173516/ [20:16:50] 3Phabricator.org: We need a Wikimedia process for filing tasks and patches upstream in the name of Wikimedia - https://phabricator.wikimedia.org/T1298#22804 (10valhallasw) I think there are three classes of bugs, seen from a s.phab.o perspective: 1) Important. Should be under the #wikimedia umbrella upstream. 2... [21:06:03] 3Code-Review: Enable Diffusion in phabricator.wikimedia.org for everybody - https://phabricator.wikimedia.org/T1294#22819 (10Qgil) [21:06:18] 3Code-Review: Enable Diffusion in phabricator.wikimedia.org for everybody - https://phabricator.wikimedia.org/T1294#22825 (10Qgil) [21:11:03] ^d about T1294, sorry for being a bit too conservative/paranoid before. You were right. [21:12:32] <^d> No worries. As long as everyone's on the same page I'm happy :) [21:15:23] along the same line of reasoning.... I think we need to enable the feed application as well as the calendar app [21:15:35] feed is enabled no? [21:15:38] I use it daily [21:16:04] how? i can't see it [21:16:09] I get 404'd [21:16:12] https://phabricator.wikimedia.org/feed/ [21:16:14] hmm [21:16:17] looking [21:16:34] public access [21:16:34] oh weird it works now [21:16:44] PEBKAC :D [21:17:04] that's really strange because I double checked it before to be 100% sure I wasn't doing something weird [21:17:09] calendar I think is a bit more...hmmm...technically still prototype [21:17:13] tho I agree would be nice [21:17:20] Please let [21:17:53] 's discuss and agree new apps on tasks. There is time. (I'm after LegalPad, fyi) :) [21:18:37] there are tasks for these things they just haven't gotten traction that's why I said something here [21:19:12] mmmnot for the feed, or it's the first time I hear about such request [21:19:41] I'm sorry it wasn't feed I was thinking of 'notification feed' but it's not the same as the feed app [21:19:44] it's the notification app [21:20:12] ah! yes, about the "flame", today I replied in the task saying that I also agree [21:20:35] https://phabricator.wikimedia.org/T1047 [21:21:06] twentyafterfour, https://phabricator.wikimedia.org/T1047#22673 exactly [21:22:33] done [21:22:40] 3Project-Management: Phabricator lacks a "notification" feed similar other project management software: Enable "Flame" - https://phabricator.wikimedia.org/T1047#22844 (10chasemp) done [21:23:02] Send emails to everybody who has ever voted in Bugzilla: ~4000 people. Google allows 100 CC entries per email. That will be... fun. :-/ [21:23:48] andre__, ouch [21:24:01] well yeah. I kind of expected that :P [21:24:05] well, then we have a good argument not to do this [21:24:13] do we? [21:24:14] andre__: use a mail merge maybe? not sure if gmail is OK with doing that for 4000 recipients though [21:24:21] (I didn't, silly me) [21:24:23] I think it'll work [21:24:33] or, you know, 40 mails. It's not that much :-p [21:24:55] (probably faster than figuring out how to do a mail merge for gmail) [21:25:07] yes gmail sucks for thsi kind of thing for sure [21:25:08] yeah [21:25:11] andre__, is there a way to filter those, say, with less than 10 votes? [21:25:17] qgil, sure [21:25:23] but that's not what was requested :) [21:25:59] sure, but we can say that less than 10 is fairly simple to follow and CC yourself manually, and this would cut the number of spam from 4000 to ? [21:26:02] andre__: you already sent an e-mail to everyone with an account, right? was that with a different method? [21:26:25] qgil: SELECT who FROM votes GROUP BY who HAVING COUNT(who) > 9; says 329 [21:26:37] 329 sounds like a very good number to me [21:26:38] SELECT who FROM votes GROUP BY who HAVING COUNT(who) > 4; 732 [21:26:59] 732, not bad. Your call. [21:26:59] ok notifications are enabled (not real time) [21:27:00] https://phabricator.wikimedia.org/notification/ [21:27:09] chasemp, thank you! [21:27:11] one less :) [21:27:15] it's kinda funky to get used to (IMO) I never use to them any great extent but they can be helpful [21:27:40] chasemp, I think they make more sense for users not having lots of daily notifications [21:27:44] but yes, agreed [21:28:02] it does allow you to forgo email [21:29:15] valhallasw`cloud, we sent the 2 notifications to about 800 users active in the past 12 months (or so), not to all Bugzilla users [21:29:19] qgil: how goes using conpherence? [21:29:27] I like it [21:29:32] qgil: ahhh, that explains [21:30:05] I think we will open it up, but I'd like to have some tangible proof before starting a potentially bikeshedding discussion [21:30:23] I was thinking it would be cool if projects game with a conpherence channel along with a workboard [21:30:35] best place to ask ppl associated async non-issue specific questions [21:30:38] oops, meeting [21:30:39] and easy way to know WHO to ask [21:30:47] (yes yes) [21:32:20] valhallasw`cloud: did you ever find any besides 896 that were affected by the \x0e thing https://phabricator.wikimedia.org/T815#20784 [21:37:25] chasemp: what if we made a 'meta' task in maniphest for the project that way comments on the task would show on the project feed [21:37:46] or ideally if projects just had comments, that'd be even better [21:38:08] either one would work, but the second seems nicer [21:38:09] chasemp: I only found 896 [21:38:17] foo and foo+meta is kinda...well...yeah [21:38:19] messy [21:38:24] chasemp: (I also did not check for others)( [21:38:31] valhallasw`cloud: just found 7111 [21:38:34] which not sure if same or different [21:38:38] but yeah lots char mess there [21:38:44] https://bugzilla.wikimedia.org/show_bug.cgi?id=7111 [21:38:49] chasemp: we're still running without patch? [21:38:56] patch is in right now [21:39:10] trying to find outliers [21:39:12] ok. Just a sec. [21:39:15] 3Project-Management: Phabricator lacks a "notification" feed similar other project management software: Enable "Flame" - https://phabricator.wikimedia.org/T1047#22863 (10Qgil) [21:39:44] 3Project-Management: Phabricator lacks a "notification" feed similar other project management software: Enable "Flame" - https://phabricator.wikimedia.org/T1047#22872 (10Qgil) a:3chasemp [21:39:54] 3Project-Management: Phabricator lacks a "notification" feed similar other project management software: Enable "Flame" - https://phabricator.wikimedia.org/T1047#22873 (10Qgil) 5Open>3Resolved [21:40:30] (Pdb) '\x0e' in data [21:40:30] True [21:40:33] (for 7111) [21:40:44] ah nice idea to test [21:40:48] ok got it [21:41:07] chasemp: assuming you're using minimal.py, run it with python -i minimal.py 7111 [21:41:20] that will give you [21:41:22] File "/home/valhallasw/tmp/xmlrpclib.py", line 563, in feed [21:41:23] self._parser.Parse(data, 0) [21:41:41] then on the >>>, enter import pdb; pdb.pm() to start the debugger [21:41:45] meh running the actual fetch script, I guess that would be quicker [21:41:51] but I wanted to see it all work "for real" [21:41:52] 3951 vote user [21:42:08] you could ask FR to make mail campaigns for you, using silverpop [21:42:16] chasemp: well, run it with -i to get a shell after it crashes, then use pdb to debug [21:42:41] thanks, I rarely think of pdb [22:30:29] Is there any way to bulk act on all tasks in a given column in a board? I want to mark a lot of things as closed that are in our Done column. [22:31:36] afaik there isn't [22:31:43] boo [22:31:55] * bd808 will click lots of times [22:32:03] yeah, good thought tho [22:34:25] 3Bugzilla-Migration: Special landing page to redirect Bugzilla and Phabricator users during the migration - https://phabricator.wikimedia.org/T1267#22898 (10Qgil) [22:34:37] hm, search also doesn't allow filtering by workboard [22:38:15] 3Project-Management, Phabricator.org: Easily close all tasks in a particular workboard column - https://phabricator.wikimedia.org/T1284#22909 (10Qgil) [22:39:28] qgil: in theory Nemo's steps are nice. In practice they will NOT work without editbugs membership. [22:39:39] I feel like I just wasted an hour before realizing that. Meh. [22:39:42] (re: votes) [22:39:56] andre__, meh indeed... :( [22:40:11] let me see... [22:40:19] but great that I fiddled with that SQL query. Garrrr. :( [22:41:55] "Change Several Bugs at Once" -- true, no way around this [22:41:58] 3Bugzilla-Migration: Send two email notifications to active Bugzilla users asking them to join Phabricator - https://phabricator.wikimedia.org/T618#22934 (10Aklapper) >>! In T618#22582, @Nemo_bis wrote: > IMHO worth sending a separate email with subject "Migrate your Wikimedia bugzilla votes now" to all the user... [22:42:13] and if you are left with manual CCs... then you can also do the manual CCs after the migration, same thing [22:42:41] andre__, I think you can paste the relevant fragments of this discussion now and before as a reply to Nemo in that task. [22:43:23] I also feel kinda stupid for encouraging you to do it... I owe you one hour on something :P [22:43:40] not really. Being a bugwrangler requires masochism, see job description. [22:43:57] qgil, well, still, subscribing to CC explicitly BEFORE migration makes sense. less manual work afterwards [22:44:15] but in this case... hmpf. [22:44:26] is it that editbugs doesn't work in read-only [22:44:36] ^andre [22:44:37] it's a group membership [22:44:51] it's the name of a group. if you don't have editbugs you cannot change the status of a ticket in BZ [22:45:01] sure but if it's all read-only [22:45:02] so not sure if I get your question right :) [22:45:06] would it matter to dump all users in there? [22:45:09] to they could do it [22:45:16] this is an action that needs to be done before read-only [22:45:20] 3RT-Migration, Bugzilla-Migration: Communicate the launch of Wikimedia Phabricator Day 1 - https://phabricator.wikimedia.org/T188#22955 (10gpaumier) FYI, today's tech newsletter featured the Bugzilla-to-Phabricator migration prominently: https://meta.wikimedia.org/wiki/Tech/News/2014/47 It was also mentioned on... [22:45:22] the point is that people explicitly CC themselves on ticket *before* migrating [22:45:23] otherwise what's the point [22:45:25] ok that's my question yep [22:45:29] so they don't have to go thru tickets one by one to subscribe [22:45:35] just making sure I understand [22:45:38] yeah [22:46:08] * andre__ looks for beer in the fridge and wonders what he originally wanted to work on :) [22:46:23] andre__: you wanted to send 40k mails, then go to cross [22:47:37] mutante, well, that's a bit mood now - sending instructions that won't work for half of the people doesn't make sense [22:47:57] i didn't know about the "won't work" part [22:52:44] * qgil extends https://commons.wikimedia.org/wiki/File:Flaeschebier.jpg to andre__ [22:53:53] (the idea is that you choose one, not necessary all) [22:54:14] heh. Right now I have this one next to me: https://upload.wikimedia.org/wikipedia/commons/d/d5/Staropramen_Gran%C3%A1t.jpg [22:54:54] should work [22:55:00] but thanks :) [22:55:15] seems like a smorgasbord of beers to me [22:55:21] really it would be rude to not try all [22:57:04] you should go to FOSDEM conference. [22:57:07] that's beer heaven. [22:57:34] Kueppers Koelsch.. hah [23:40:45] 3Wikibugs, Bugzilla-Migration: IRC bot to report Phabricator activity exactly like Wikibugs does with Bugzilla - https://phabricator.wikimedia.org/T131#22992 (10Quiddity) [23:40:46] 3Wikibugs: phawikibugs should Ignore CC changes - https://phabricator.wikimedia.org/T647#22990 (10Quiddity) [23:51:59] If I'm creating a lot of tasks automatically, enough to where the creation of tasks seems to be throttled by PhabricatorTaskmasterDaemon...is it sane to stop phd, craete my tasks, then start it. will it catch up on backlog and sort itself out? [23:53:18] twentyafterfour: ^ the services all handle backlog gracefully right? [23:57:07] chasemp: I'd say it should handle the backlog, yes [23:57:37] though things might complete faster if you have the workers working while you're still in the process of creating the tasks [23:58:35] I'm not sure if phd is required in order for it to enqueue the tasks. Also, you can stop individual daemons without stopping phd entirely [23:58:45] that's a good thought