[21:01:02] To be honest, looking at many technically orientated wikimedia channels is a pain in my opinion. You can't do anything sat #wikimedia-dev because of a spamming gerrit-bot (single user at my ignore list until now) and many channels are quite dead, maybe because there are so many similar ones. For exmple, look at #wikimedia-dev and wikimedia-tech, can you really divide their topics? [21:01:39] No human wants to be in a channel where 9 of 10 messages are posted by a bot [21:27:46] MGChecker: I agree, we have a bot overload on most of our channels [21:35:52] twentyafterfour: I really think +1/-1 actions shouldn't be shown in non-feed channels, but I don'T know where to propose something like this [21:38:13] twentyafterfour: Do you have some time in circa half an hour to review a really little follow up to the patch you merged yesterday? [21:38:27] MGChecker: sure [21:44:46] I think dispalying -1 is useful, because in that case the author needs to write a second set [21:45:38] Yes, but it isn't anything critical about your bug that changes its feature drastically. [21:46:16] It isnÄt weorth it to make a complete channel unusable, that could actually be an nice place for dicussions if the bug wouldn't post so much [21:46:48] I'm not even sure if divided -tech and -dev channels would be needed anymore [21:47:01] that's why I'm making the bot quite here, if there is no code review hour currently ;) [21:48:06] It would be more practical of the bot has another nick, so I can see what he posts. [21:49:03] Because in the current situation, I can'T hanlde the flood in -dev while being interested what the people there are talking about [21:49:33] MGChecker -1 will go away when we migrate to diffusion. [21:49:55] Instead -1 is considered request changes. And +1 i think is accepted. [21:51:04] I worked with Diffusion in a smaller community, I don't really think it's so good for an really large group of users in the current state, to be honest I don't even know how to do +2... [21:51:17] Isn't -1 Request changes in the current situation too? [21:52:04] MGChecker it is accepted. You arc land or arc land [21:52:24] Hm, okay. [21:52:34] but you doint really need accepted since you can merge without accepted. [21:53:50] Nevertheless I'm skeptical how this will work in praxis [21:54:12] *practice [21:56:38] I have got a question about code review office hours: Is it possible that a patch is too big fpr such an hour? [21:57:46] MGChecker, ive improved diffusion a bit. twentyafterfour: Enabled importing all changes from refs/changes/ from gerrit. Also differential if you think things can be improved on and have ideas please could you post them upstream on secure.phabricator.org so they can be considered please. [21:58:24] MGChecker also i added downloading branches here git checkout -b D233 && curl -L https://phabricator.wikimedia.org/D233?download=true | git apply [21:58:24] D233: Add support for downloading branches from diffusion gui - https://phabricator.wikimedia.org/D233 [21:58:28] Wrong link [21:58:33] https://phabricator.wikimedia.org/D233 [21:58:40] That one ^^ [21:59:16] Hm, looks like you won't be migrating before diffusion can do nearly everyhting gerrit could do in a similar way [22:00:36] *Diffusion and related tools [22:00:42] That's nice ^^ [22:02:02] Yep [22:02:31] How jenkins will work at phabricator? [22:06:14] via harbormaster [22:07:05] I see [22:08:06] MGChecker but zuul wont work with phabricator. [22:08:44] What are the conseuqences? I vaguely know what it does, bt nocht exactly [22:09:34] twentyafterfour: Okay, I was right, that users without managechangetags couldn't delete tags was a pure GUI problem, API deleting works without the permission. I'll upload a patch in a few minutes. [22:09:56] MGChecker you wont get the pretty zuul ui any more. Im not sure how jobs will be configured since they are all done through zuul config file. [22:10:24] Im not sure how easy it will be to view open tests running like zuul. [22:10:32] hm [22:11:08] But there is a task on this and they are looking into it since zuul adding support for other things other then gerrit. [22:11:19] *Looking into but not upstream. [22:11:54] hm, okay [22:14:09] paladox: at zuul upstream? [22:15:13] twentyafterfour: https://gerrit.wikimedia.org/r/#/c/288712/ [22:15:14] Luke081515: Well zuul have added support for things other then gerrit, so maybe it would work with phabricator if we figure out how to do it. I think hashar is planning on doing testing in the summer but not sure. [22:16:05] ok [22:16:35] my opinion is that we should wait with the migration, because differential isn't ready in my opinion for review with users who are not real trusted [22:17:40] Why do you think so? A review isn't the same as a merge. Or do I miss something? [22:18:10] at differential you can merge without any review, that's the problem [22:18:22] and you can directly push too [22:18:43] Luke081515: Maybe we can report that upstream so that we can add someway of veryingfing if the user can +2 or not [22:19:15] So maybe reviewers who can merge should show up as green and users who can only accept can accept. [22:19:24] That way we will be able to tell the difference. [22:19:31] twentyafterfour ^ [22:20:09] we can use blocking reviewers, But: [22:20:15] * would require a lot of herald rules [22:20:17] * and ACLs [22:20:23] * and you can merge anyway [22:20:39] I already made a proposal upstream, lemme search [22:21:25] https://secure.phabricator.com/T10574#165181 [22:21:43] Luke081515 but isen't reviewing the same in gerrit. Anyone can review but not everyone can merge. [22:22:54] ^ [22:23:02] paladox: everyone with push access can merge, with and without review [22:23:06] that's the problem [22:23:21] Luke081515 oh but you can do that in gerrit too. [22:23:27] But push access only have people woh would have +2 in gerrit too [22:23:39] there is a way to make a workaraound without an differential change, but would require lot's of zuul config [22:24:00] MGChecker: ok, who would create the 800 projects for all mediawiki extensions? That's too much [22:24:09] and we have more than extensions [22:24:13] Luke081515 not sure. But they have to arc land. [22:24:31] I think this is the only possible way, doesn'T gerrit do it basically the same? [22:24:37] paladox: you can merge without arc too. and arc land is even possible, if no one accepted the change [22:24:55] MGChecker: See 00:23 [22:25:13] Luke: about MGChecker: ok, who would create the 800 projects for all mediawiki extensions? That's too much [22:25:21] Luke081515 but anyways people who can merge are trusted users so unlikly that any of them going to merge without review but yes i think that someone should have the ability to +1 or +2 which merges. [22:25:44] paladox: but we need tons of ACLs then [22:25:51] Luke081515 you can make it require accepted. By a config change [22:26:01] paladox: phab or arc? [22:26:03] But that will affect all projects which doint want to do that. [22:26:13] phab [22:26:24] paladox: but than anyone can accept [22:26:34] No [22:26:45] why not? [22:26:55] Oh wait yes anyone can sorry about that [22:27:06] But you carn't accept your self with http://www.test-random-wikisaur.tk/config/edit/differential.allow-self-accept/ [22:28:18] yep, but you only need to create a sock [22:28:25] quite easy if you wanna make damage [22:28:58] Oh [22:31:36] twentyafterfour: Is there a way we can get upstream to support showing users that can merge (Tell the difference like you can in gerrit.) In gerrit it shows a grey box in +2 for v which tells you the user carn't merge [22:31:59] Luke081515 you can overide in gerrit too.