[20:26:31] legoktm: I thought about it more, and I think that REL1_* branches should use vendor as a submodule too, just like wmf/* branches [20:26:39] The only time you'd run composer yourself is on master. [20:27:03] If you're doing it on a branch? Yes, you'll end up with modified files in the tree....but that's to be expected? [20:30:39] Also: I think the easiest way to do security releases is to push to gerrit, immediately tag upon merge, then do tarballs. [20:30:48] Having the tarballs first makes the whole process a pain in the ass. [20:31:08] (which is why we wait until we have multiple issues to bundle, which means long jenkins time-to-merge) [20:31:40] We can send the announcement as soon as patches are live, with links saying "Hey, tarballs will be here shortly, but if you need to patch faster here's the git info" [20:33:34] Plus, lets me rip out all of the "patch" logic to tarball generation [20:33:38] (which sucks) [20:35:50] no_justification: the main reason people need to run composer themselves is if they need to install dependencies for an extension that isn't bundled in the tarball [20:36:04] like CirrusSearch which requires Elastica, or SMW which has its own composer dependencies [20:36:29] we developed composer-merge-plugin so it would be possible to install local dependencies without modified files [20:37:15] Ok, fair enough [20:37:34] Who cares if files modify? [20:37:41] That shows you a diff of what you deployed vs. upstream [20:37:50] You're installing /via git/ as it is [20:37:52] Because it makes upgrading a pain since you can't just plain git pull anymore [20:38:06] Yes, you can. As long as nothing merge conflicts [20:38:11] And if it does, that's an issue anyway! [20:38:21] and we've taught people pretty well not to modify files that belong to core [20:38:39] composer's autoload files will merge conflict, pretty much every time [20:39:00] Then ignore the autoload file for changes? [20:39:26] my git upgrade strategy is to fetch, checkout new REL branch, and then pull --rebase; results in very few issues for the most part [20:39:58] alternatively, you could reset --hard [20:40:03] which should result in 0 issues [20:40:20] My default workflow is pull -r [20:40:30] For...basically everything [20:40:58] I don't think other people are that experienced enough in git to know how to do all of that [20:41:01] You could do something like --assume-unchanged or --ignore-worktree possibly for the autoload file [20:41:11] so it seems like we could just document an update strategy for git on mw.o that results in little to no issues for whatever release branch workflow we end up going with? [20:41:19] Only difference with pull and pull -r is whether you get merge commits are not [20:41:40] I think I'm missing why it's problematic to bundle vendor/ without using it as a submodule [20:42:46] I think it's weird to have two ways of installing composer deps [20:43:51] the vendor repo is a WMF prod hack [20:44:06] That too ^ [20:44:23] If `composer update` isn't secure for the tarball / can't bring in custom patches then....installing from git is less secure? [20:45:40] Yes, running composer yourself is less secure than using files that were reviewed for inclusion from a gpg-signed source [20:46:04] if you really care about security w/ git, you can use mediawiki/vendor's REL1_XX branch [20:46:07] Then why do we shoot our git-based users in the foot? [20:48:27] The alternative of course is always using composer update, and not vendor repo. As bd808 says, it's just a hack. The main problem would be in just having to sit on a 3rd party vuln for longer until it makes it out upstream. [20:48:41] because people need a way to install extra composer dependencies...? Don't know how else to balance those needs [20:50:52] use composer update for the tarball? that would work, we'd just need to make sure it includes the bundled extensions' dependencies (using merge-plugin) and that someone is reviewing what composer pulled in (and not blindly trusting composer) [20:52:42] Well, that could be the basis of the submodule, yes? [20:53:04] Would be composer update as needed for extensions (which should be master, tbh. wmf should have its own base) [20:55:54] Actually just kill master and wmf is branched from prior wmf [20:56:12] Then we'd commit any diff [20:56:22] Same with rel [21:25:42] I guess there's a first time for everything. Just saw a vandal on Phabricator that also vandalised wikis including wikis other than wikitech/mediawiki.org. https://tools.wmflabs.org/guc/?user=Chris407 / https://phabricator.wikimedia.org/p/Chris407/ [21:25:47] Some people just have too much time ... [22:02:00] User disabled