Change Details

NOTE: at this writing mwdebug1003 is on buster, don't use it mwdebug1001,2 are ok, apparently 1002 is recommended in the doc ALSO NOTE: official docs on deployment are on wikitech at https://wikitech.wikimedia.org/wiki/How_to_deploy_code and the official docs on how to do backports and deploy those are at https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers * Backporting in gerrit is a matter of figuring out which versions are deployed where that need the backport; you can look at https://versions.toolforge.org/ and then if there are entries that list multiple versions for a group of wikis, you can go to any current copy of the mediawiki-config repo, grep for the version(s) that interest you in wikiversions.json, and determine which specific wikis run those versions. once you've determined which versions should get the backport, you can do the backport directly in gerrit, by going to the merged changeset in master, in the upper right corner clicking the three dots for the extended menu, selecting "cherry pick", typing "wmf" to get the suggestion list, and as much needed of the branch to see the desired branch in the suggestion list, and choose that. The rest should be self-explanatory. * If you are the +2-er on master, you can also backport in gerrit (wait until master +2 post-merge jenkins completes, then you can do it) and +2 it there * anyone can grab a ubn ticket w/ a patch and herd it along, there is no set procedure, but it is preferred that someone on the clinic duty team grab and do it, including the deploy. * You don't have to wait for a window if it's really OMG UBN (as opposed to "we'd like it done soon but things are not on fire"), but then you do need to make sure someone from sre is around in case there are issues with the deploy, and you should announce to releng too. channels for these: #wikimedia-sre (to ask for someone to pay attention to the deploy), #wikimedia-releng (to notifiy releng), #wikimedia-operations (to discuss each step of the deploy as it happens). * If you are using a backport/deploy window, you don't need to ask for an sre since these windows are scheduled on the deployment calendar and known in advance, but you do need to add your info to the calendar: https://wikitech.wikimedia.org/wiki/Deployments you can +2 and merge the backport ahead of time but you should time it so that the merge finishes up around the start of the window or later, instead of completing well beforehand. * Verify that you can reproduce the bug that's being fixed, before you start, so that you know the procedure to check if the error is gone on the appropriate mwdebug host. * If it's not an error but a feature, verify that you know how to use the feature and test for its presence on the right mwdebug host. * If you are deploying in a window, there is a list of deployers who might manage the window on the Deployments calendar. In practice one of those people will announce that they are managing the window for that time. They will call out each person in the slot on the calendar and verify that the person is present for the deployment. Then they will go through the deployments, typically in the order listed on the calendar. This may be shuffled around if folks are waiting for patches to merge. Although the person managing the window can deploy your patch, they are usually quite happy for you to do it yourself. * On deploy1001 in /srv/mediawiki-staging/php-your-version, git status and see what is outstanding. If there are security patches committed locally but not merged, this is ok. Such patches will be listed first before the top commit of the branch, and marked as SECURITY in the commit message. If some extensions have unmerged commits, you can ignore them. IF THERE ARE OTHER CHANGES NOT MERGED OR NOT COMMITTED, STOP and get advice. * git log to see what is going on, same as above. * If all is good, git fetch to pull in your backported changes * git log to be sure only your change got pulled in; you can specifically compare your local HEAD to upstream by "git log -p HEAD..@{u}" * git merge * If there were unmerged security changes on top, git rebase (no args needed) * ssh to mwdebugX (not the one with buster), and, as your regular user, scap pull from any directory; NOTE THAT this does an rsync so it picks up everything in the directory. * Verify that your test of the bug or feature does what is expected * Back on deploy1001, from /srv/mediawiki-staging you can now do scap sync-file php-version/.../path-to-change.php "message here" A nice format for the message with the linked gerrit commit and the linked phab task is available at https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers and you should use it! Basically it is this: 'Backport: [[gerrit:GERRIT-NUMBER|COMMIT-MESSAGE (PHABRICATOR-TASK)]]' * Wait a bit for things not to explode * Profit!

NOTE: at this writing mwdebug1003 is on stretch and mwdebug1001,2 are on buster; use the buster ones for testing unless there is a stretch-specific thing you are checking. ALSO NOTE: official docs on deployment are on wikitech at https://wikitech.wikimedia.org/wiki/How_to_deploy_code and the official docs on how to do backports and deploy those are at https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers * Backporting in gerrit is a matter of figuring out which versions are deployed where that need the backport; you can look at https://versions.toolforge.org/ and then if there are entries that list multiple versions for a group of wikis, you can go to any current copy of the mediawiki-config repo, grep for the version(s) that interest you in wikiversions.json, and determine which specific wikis run those versions. once you've determined which versions should get the backport, you can do the backport directly in gerrit, by going to the merged changeset in master, in the upper right corner clicking the three dots for the extended menu, selecting "cherry pick", typing "wmf" to get the suggestion list, and as much needed of the branch to see the desired branch in the suggestion list, and choose that. The rest should be self-explanatory. * If you are the +2-er on master, you can also backport in gerrit (wait until master +2 post-merge jenkins completes, then you can do it) and +2 it there * anyone can grab a ubn ticket w/ a patch and herd it along, there is no set procedure, but it is preferred that someone on the clinic duty team grab and do it, including the deploy. * You don't have to wait for a window if it's really OMG UBN (as opposed to "we'd like it done soon but things are not on fire"), but then you do need to make sure someone from sre is around in case there are issues with the deploy, and you should announce to releng too. channels for these: #wikimedia-sre (to ask for someone to pay attention to the deploy), #wikimedia-releng (to notifiy releng), #wikimedia-operations (to discuss each step of the deploy as it happens). * If you are using a backport/deploy window, you don't need to ask for an sre since these windows are scheduled on the deployment calendar and known in advance, but you do need to add your info to the calendar: https://wikitech.wikimedia.org/wiki/Deployments you can +2 and merge the backport ahead of time but you should time it so that the merge finishes up around the start of the window or later, instead of completing well beforehand. * Verify that you can reproduce the bug that's being fixed, before you start, so that you know the procedure to check if the error is gone on the appropriate mwdebug host. * If it's not an error but a feature, verify that you know how to use the feature and test for its presence on the right mwdebug host. * If you are deploying in a window, there is a list of deployers who might manage the window on the Deployments calendar. In practice one of those people will announce that they are managing the window for that time. They will call out each person in the slot on the calendar and verify that the person is present for the deployment. Then they will go through the deployments, typically in the order listed on the calendar. This may be shuffled around if folks are waiting for patches to merge. Although the person managing the window can deploy your patch, they are usually quite happy for you to do it yourself. * On deploy1001 in /srv/mediawiki-staging/php-your-version, git status and see what is outstanding. If there are security patches committed locally but not merged, this is ok. Such patches will be listed first before the top commit of the branch, and marked as SECURITY in the commit message. If some extensions have unmerged commits, you can ignore them. IF THERE ARE OTHER CHANGES NOT MERGED OR NOT COMMITTED, STOP and get advice. * git log to see what is going on, same as above. * If all is good, git fetch to pull in your backported changes * git log to be sure only your change got pulled in; you can specifically compare your local HEAD to upstream by "git log -p HEAD..@{u}" * git merge * If there were unmerged security changes on top, git rebase (no args needed) * ssh to mwdebugX (not the one with buster), and, as your regular user, scap pull from any directory; NOTE THAT this does an rsync so it picks up everything in the directory. * Verify that your test of the bug or feature does what is expected * Back on deploy1001, from /srv/mediawiki-staging you can now do scap sync-file php-version/.../path-to-change.php "message here" A nice format for the message with the linked gerrit commit and the linked phab task is available at https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers and you should use it! Basically it is this: 'Backport: [[gerrit:GERRIT-NUMBER|COMMIT-MESSAGE (PHABRICATOR-TASK)]]' * Wait a bit for things not to explode * Profit!

NOTE: at this writing mwdebug1003 is on buster, don't use itstretch and mwdebug1001,2 mwdebug1001,2 are ok, apparently 1002are on buster; use the buster ones for testing unless there is recommended in the doca stretch-specific thing you are checking. ALSO NOTE: official docs on deployment are on wikitech at https://wikitech.wikimedia.org/wiki/How_to_deploy_code and the official docs on how to do backports and deploy those are at https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers * Backporting in gerrit is a matter of figuring out which versions are deployed where that need the backport; you can look at https://versions.toolforge.org/ and then if there are entries that list multiple versions for a group of wikis, you can go to any current copy of the mediawiki-config repo, grep for the version(s) that interest you in wikiversions.json, and determine which specific wikis run those versions. once you've determined which versions should get the backport, you can do the backport directly in gerrit, by going to the merged changeset in master, in the upper right corner clicking the three dots for the extended menu, selecting "cherry pick", typing "wmf" to get the suggestion list, and as much needed of the branch to see the desired branch in the suggestion list, and choose that. The rest should be self-explanatory. * If you are the +2-er on master, you can also backport in gerrit (wait until master +2 post-merge jenkins completes, then you can do it) and +2 it there * anyone can grab a ubn ticket w/ a patch and herd it along, there is no set procedure, but it is preferred that someone on the clinic duty team grab and do it, including the deploy. * You don't have to wait for a window if it's really OMG UBN (as opposed to "we'd like it done soon but things are not on fire"), but then you do need to make sure someone from sre is around in case there are issues with the deploy, and you should announce to releng too. channels for these: #wikimedia-sre (to ask for someone to pay attention to the deploy), #wikimedia-releng (to notifiy releng), #wikimedia-operations (to discuss each step of the deploy as it happens). * If you are using a backport/deploy window, you don't need to ask for an sre since these windows are scheduled on the deployment calendar and known in advance, but you do need to add your info to the calendar: https://wikitech.wikimedia.org/wiki/Deployments you can +2 and merge the backport ahead of time but you should time it so that the merge finishes up around the start of the window or later, instead of completing well beforehand. * Verify that you can reproduce the bug that's being fixed, before you start, so that you know the procedure to check if the error is gone on the appropriate mwdebug host. * If it's not an error but a feature, verify that you know how to use the feature and test for its presence on the right mwdebug host. * If you are deploying in a window, there is a list of deployers who might manage the window on the Deployments calendar. In practice one of those people will announce that they are managing the window for that time. They will call out each person in the slot on the calendar and verify that the person is present for the deployment. Then they will go through the deployments, typically in the order listed on the calendar. This may be shuffled around if folks are waiting for patches to merge. Although the person managing the window can deploy your patch, they are usually quite happy for you to do it yourself. * On deploy1001 in /srv/mediawiki-staging/php-your-version, git status and see what is outstanding. If there are security patches committed locally but not merged, this is ok. Such patches will be listed first before the top commit of the branch, and marked as SECURITY in the commit message. If some extensions have unmerged commits, you can ignore them. IF THERE ARE OTHER CHANGES NOT MERGED OR NOT COMMITTED, STOP and get advice. * git log to see what is going on, same as above. * If all is good, git fetch to pull in your backported changes * git log to be sure only your change got pulled in; you can specifically compare your local HEAD to upstream by "git log -p HEAD..@{u}" * git merge * If there were unmerged security changes on top, git rebase (no args needed) * ssh to mwdebugX (not the one with buster), and, as your regular user, scap pull from any directory; NOTE THAT this does an rsync so it picks up everything in the directory. * Verify that your test of the bug or feature does what is expected * Back on deploy1001, from /srv/mediawiki-staging you can now do scap sync-file php-version/.../path-to-change.php "message here" A nice format for the message with the linked gerrit commit and the linked phab task is available at https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers and you should use it! Basically it is this: 'Backport: [[gerrit:GERRIT-NUMBER|COMMIT-MESSAGE (PHABRICATOR-TASK)]]' * Wait a bit for things not to explode * Profit!