Tue, Apr 24
Now we need to actually run the updated script on Wikimedia wikis. We should also cherry-pick the patch for populateRevisionLength.php to REL-1.31 as we did for the other patch.
Sat, Apr 21
Also, once the script has finished going all the way to 23 February 2018, we should also do another run of the script for autopatrol entries from 23 February 2018 to 5 April 2018, as well as those old ones that still have 'log_action = patrol', with the information included in the log_params field instead.
We still need to update the populateRevisionLength.php script to fix the rev_len or ar_len field for revisions where the field is zero but is "supposed" to be a nonzero value.
Thu, Apr 19
@Ladsgroup The next patch you might want to upload is to request that the following lines (110 to 113) be completely removed from the InitialiseSettings.php file.
Mon, Apr 16
Sat, Apr 14
Sun, Apr 8
Thu, Apr 5
Wed, Apr 4
Tue, Apr 3
Mon, Apr 2
I tried to fix the description to make it look more like an actual RfC. This means that I moved this back to the "Inbox" column on the TechCom-RFC board.
Sun, Apr 1
Thu, Mar 29
Mar 27 2018
Since Anomie's Code-Review -2 on the Gerrit patch that I have abandoned made this controversial, I decided to make this an RfC. If consensus is established, I will upload a new patch from scratch instead of restoring the abandoned patch.
Mar 23 2018
Mar 22 2018
Should we reinstall Flow on enwiki and metawiki and set $wgFlowReadOnly to true on those 2 wikis then, as we did for Commons?
Mar 19 2018
For entries prior to April 2016, the script should check the log_params field to determine autopatrol status. It is absurd to kill all the manual patrol entries before then, because it would give the incorrect impression that the log has never existed prior to April 2016. Only autopatrols should be killed off. Otherwise, the manual patrols prior to April 2016 should be moved to a temporary "backup" table that will then be remerged back to the original logging table.
Mar 16 2018
Mar 15 2018
No longer neccessary as T188826 has been resolved.
Mar 13 2018
Can anyone please do an SQL query that prints out a list of revisions on Wikipedia whose rev_parent_id is not the rev_id for an existing row in the revision table, but instead the ar_rev_id for a row in the archive table, that will be affected by the script?
Mar 8 2018
Either run this, or switch to using log_actor and the newly created actor table. T188826 has already been fixed.
Mar 7 2018
When I save an edit on Wikipedia, it still says "Your edit was saved", not "Your edit was published". I am thus reopening this, which needs a more careful patch to be actually fixed.
Mar 6 2018
The request to run the script has been created as T189043.
This could also be fixed by running the populateLogUsertext.php script. It seems that that script has never been run for old log entries prior to September 2009.
Mar 2 2018
Feb 25 2018
No longer relevant now that T181731 has been run.
Feb 24 2018
Yes, the message is currently misleading. The patch has now been uploaded.
Categories are intentionally set up to show pages in all namespaces. Adding a drop-down box containing namespaces to filter by requires starting an RfC for consensus.
Feb 23 2018
Feb 20 2018
Feb 19 2018
Feb 16 2018
@Graham87 @Addshore Would you two be able to take a look at this? As another example, the history of Talk:Po (disambiguation) clearly shows the earliest revision with a nonzero parent id despite the page being undeleted.
Feb 15 2018
Feb 14 2018
Feb 13 2018
Feb 10 2018
Feb 9 2018
Feb 4 2018
Feb 3 2018
Feb 1 2018
Jan 29 2018
@MGChecker Well, the same problem would also occur with patrol log entries as well. If you think that this isn't a good idea, then probably T27799 shouldn't have been a good idea either, then. But that was already fixed for newer log entries. Too late to worry about that, sorry. A task similar to T136493 will have to be created for fixing older move log entries.
Jan 24 2018
The following 2 examples show that using the parent id from the archive table might be a problem in the case of selective undeletion: revision 821925874 in the history of Kurdish National Congress and revision 435909482 in the history of The Strange Familiar (which was actually originally part of "User:Lotsamuzak101/The Strange Familiar"). They look like they are new-page creations, but they do not actually show the "N" mark when viewing the user's contributions page. Their parent ids are actually 821819956 and 435904177 respectively (which you can find out by using exportation). Those two ids will display an error when you try to view them. Perhaps, in the mean time, we should add a maintenance script to change the parent ids for all revisions with "broken" parent ids to zero. Then they will show the "N" mark in the user's contributions page.
Jan 22 2018
I have changed the proposed default checked status to "unchecked" instead to match the default for the "Assign edits to local users where the named user exists locally" checkbox in Special:Import. In general, resetting may only be necessary in the case of selective undeletion, when one of the ar_parent_id values might be an unselected revision that will still remain in the archive table after undeletion.
Jan 19 2018
Whether to reset parent ids or not depends on the scenario. When undeleting pages that have been deleted and recreated several times, it might be better to leave the parent ids for the recreations as zero, but when doing history splits or merges, the better option is to reset the parent ids. The checkbox should be based on judgement, just like the "Assign edits to local users where the named user exists locally" checkbox when doing an import.
Jan 18 2018
@Lahwaacz I have fixed the description to clarify the meaning. I mean the previous revision by id (usually also by timestamp, but not always).
Jan 17 2018
Actually, what used to happen is that the rev_parent_id was automatically determined based on comparison of the rev_id values, which usually produced a nonzero value. Now the problem seems to be partially solved, but see T185167 for adding something to the undelete interface to mimic the old behavior.
Seems obvious that we need this.
Jan 3 2018
Dec 29 2017
Looking at the blocklist, there are 11 rows all by Jon Harald Søby from 2008. To completely get rid of all the rows, we need to try unblocking 11 more times. I suspect that all 15 users blocked by Jon Harald Søby on 9 July 2008 were merged into FuzzyBot by Nike the following day (the actual information is hidden from the log entries because of the use of RevisionDelete by the same admin). If so, then the rows must have came from blocks of users who originally had other usernames but were later merged into a single username.
Dec 27 2017
With the actor table, T27377 will need to be updated. This means that we'll then have 'af_actor', 'afh_actor', and 'afl_actor' instead of 'af_user', 'af_user_text', 'afh_user', 'afh_user_text', 'afl_user', and 'afl_user_text'.