[00:52:32] vinvin: maybe [00:53:06] but note the call would be Title::newFromText( $i->rc_title )->getFullUrl() [16:58:22] Coolest Tool Award live stream starts in 2 minutes -- https://www.youtube.com/watch?v=cdnwhDAdrxE [21:07:10] Is mediawiki moving out of phabricator to gitlab? [21:07:32] there are no plans to stop using Phabricator at the moment [21:08:20] but code review will be moving from Gerrit to gitlab.wikimedia.org eventually [21:09:16] I assume the reason to not use phabricator code review is due to arc usage and not git-focused? Thanks for the reply :) [21:18:43] frankly, I'm not really sure [21:19:08] https://phabricator.wikimedia.org/T119908 was the RfC task, but it appears things just kinda...fizzled out [21:22:23] someone who was around at the time might know more, but I believe it had to do with the review workflow and getting CI working [21:22:44] (which, incidentally, are the two main obstacales in the GitLab migration) [21:47:03] AntiComposite, trepatud1: migrating was mostly killed by arc in the end. The SRE team did not want a workflow that required a PHP client to submit patches. But I think if that had not killed it general dislike of the workflows required by Differential would have. [21:47:49] * bd808 tried Differential for 2-3 projects and found it very lame compared to gerrit [21:49:27] I can't say that I personally find the gitlab PR workflow to be delightful either, but it is at least not a unique invention [21:51:05] gitlab PT workflow is pretty common, indeed [21:51:25] I know a lot of people that use arc and the differential way of doing things eventually love them but it's too big of a change to request outsiders [21:53:13] yeah, it's going to take some getting used to going from gerrit's mailing list-style commit-based workflow to the GitLab branch style [22:16:54] gitlab is definitely more standard... but I would be lying if I didn't say I find the way Gerrit is structured and organized perhaps a bit nicer [22:17:52] Its design also seems to lead to a rather nicer "workflow" of contributions that seems especially suitable for these large-scale projects, and I think that might be lost in GitLab/Hub style PRs. [22:22:28] gerrit was designed based on the mailing list workflow that git was originally designed for (and what the Linux Kernel still uses) [22:23:20] which is why it deals with versions of the same patch instead of commits stacked on top of each other [23:13:59] The biggest thing from gerrit that I am going to miss in gitlab is amending someone else's patch. [23:14:49] The biggest thing many more people are going to miss is cross-repo merge blocking via Depends-on footers [23:15:25] yeah, that might be a problem :) [23:15:45] Solution: don't move to gitlab, change is bad [23:26:33] we/osgeo have gitea for source code, trac for tickets .. it is less popular with teams each year as the gravity towards BIG_GIT_SITE is so strong [23:26:48] switching costs are a thing [23:27:24] irony is that trac is better each year [23:27:59] gravity is one term, lockin for security requirements a second, to be frank [23:29:55] it would almost certainly be more difficult to move off of Phabricator for bug tracking than change code review [23:30:15] it's too good at doing what we need it to do, most of the time :) [23:30:27] :-) [23:30:34] I do /quite/ like phab [23:30:48] bd808: yeah, amending patches feels painful in the PR workflow, especially for really lighweight stuff like the commit message [23:30:51] it's really one of the best issue trackers (among many other things) that I've ever personally used [23:31:08] legoktm, for that stuff you can always rebase and merge, to be fair [23:31:11] I *really* like GH/GL's pull request template feature [23:31:19] that would be a squash and merge [23:31:29] I think either, right? [23:31:37] (rebase and merge ftw) [23:31:38] perryprog: I'm not following, how does that help edit the commit message? [23:31:42] chaining PRs is basically impossible too. Maybe that's a good thing, but it is going to break some folks heads [23:32:03] with a rebase and merge, all the commits on the branch are merged, in order [23:32:21] with a squash and merge, all the commits are combined into a single commit that is merged [23:32:46] gitlab.com has a PR dependency feature, but AFAICT it just prevented you from merging the dependent one until the parent is merged. It doesn't actually reduce the diff to parent...dependent [23:32:48] squash and merge would be the closest to the Gerrit workflow, just adding new commits instead of ammending [23:32:56] AntiComposite: do you use CLI git directly in your workflows? [23:33:28] rebase and merge allows you to modify commits, no? [23:33:36] à la rebase -i? [23:33:44] legoktm: I think that gitlab.com feature is a pay for add-on rather than part of their oss edition [23:33:55] open core is the worst [23:33:58] ^ [23:34:24] I'm not usually on the maintainer side of things but the main place I do open-source contributions for does strictly rebase-and-merge only for PRs and that allows maintainer-side of modifying commit messages, commit contents, etc. [23:35:29] that's the other thing with GitHub and GitLab, is they're an abstraction on top of what git is actually doing [23:36:18] perryprog: oh sorry, I should have clarified. I meant editing from the *web UI*, which Gerrit makes super convenient [23:36:25] yes, using the Git CLI it's still doable [23:36:34] oh yes, that's absolutely a pain in the real end compared to Gerrit [23:36:46] and that's saying something [23:36:57] Hey, Gerrit's fairly intuitive... [23:37:08] if you understand git :) [23:37:18] The main argument for moving off of gerrit has been that learning gerrit is too hard. I really don't think that gitlab will suddenly make it easier to contribute patches to MediaWiki and friends, but time will tell I suppose [23:37:20] And I'm saying that as someone who came from a GH/pr-based background and didn't know about patch-based code review [23:37:31] >if you understand git [23:37:31] oh, yeah, then I'm an exception [23:37:44] https://www.youtube.com/watch?v=1ffBJ4sVUb4 [23:37:56] thats the one that worked for me! [23:38:50] * darkblueb sorry for the YTube, but I really like that video [23:40:12] I feel it'll tip the scales to make casual contributions easier, but I worry it will make complex contributions much harder [23:41:03] yes, I fear it will make people start saying things like "monorepos are cool and useful" [23:42:07] shut [23:42:10] watch your mouth, AntiComposite [23:42:16] https://phabricator.wikimedia.org/T268283#7307390 "I'd personally love a real monorepo" ;-) [23:42:22] noooo [23:42:25] the world is doomed [23:42:59] be your own stars, WMF [23:43:28] (I don't actually have a very strong anti-monorepo opinion but I've had pains with them enough that I have a minor aversion to them at times) [23:43:33] (They aren't really /that/ bad though) [23:44:18] with (only) fifty projects in at least six (programming) language groups, we are in no danger of monorepo'ism.. also disparate teams [23:44:40] * darkblueb speaks with residential DSL line to OSUOSL, too [23:46:47] I personally think monorepos are gross. [23:47:34] considering the number of random half-broken unmaintained extensions on gerrit...