Was there any discussion related to this at the Developer Summit? Would this be a good topic for an ArchCom discussion?

From talking with Jdforrester, it sounds like ArchComm has already discussed this and the plan is to refactor the revision table (as part of the work on multi-content revisions) and in the process move edit summaries to another table (with a larger field). @daniel, would you say that is accurate?

I know next to squat about databases, so I apologize if this is incredibly dumb or obvious. Would it help to: Create the new comment table as write-only, fill it at leisure, and switch all reads&writes to the new table after it fully mirrors the existing data? Then increase the comment limit and clean up the old unused data at leisure.
That at least avoids the need to check both places during reads.

Alsee - I do not think anybody here is worried about the deployment, but there were many discussion about design and performance.

In the end, the most important part is "show me the code"- someone has to write the code and make it work -*not* the alters/create table, the changes to all core functions (and extensions, if they touch these tables), and the fixes for all external labs-based bots and gadgets, plus maintenance scripts modifications. In most cases this was delayed because not being a simple change, other refactoring was being researched to be done at the same time- https://www.mediawiki.org/wiki/User:Brion_VIBBER/Compacting_the_revision_table_round_2 .

Your proposal is quite normal- although it is not as simple as put it- code deployment to 200 apps servers take 1-2 minutes, plus long running requests can continue running for minutes, so it is not a transactional change- filling/altering the revision table can take days -up to 5- per db server (and we have >100 of those), by the time it has been filled in, new revisions have been added, and you will never be able to catch up 100%, but again nothing that cannot be done in a slightly different way as long as the code is ready. That is why new deployed code has to work independently if a schema change is ready- it takes time to be deployed, and can be deployed asynchronously- even minutes apart- on different servers.

This is not about deployment, this is about architecture and programming. Please join the discussion about that at: T153333

This will be done as stated on T174569, no longer blocked on schema change.

I suppose an announcement is due once T185948 is resolved?

T185948 pretty much is resolved, other than the vague "anything else" bullet.

I'll include it in the Tech News issue that goes out on Monday.

In T6715#4017386, @Anomie wrote:

While there's still some backend cleanup work needed (see T166733), comments longer than 255 bytes are now allowed.

This shouldn't have been just done on the fly, as this is entirely surprising for most users. Furthermore, I doubt it's even wanted like it works right now; see T6714 for example.

I believe that such a concern would belong in T6714 since that is the task for edit summary length.

@MGChecker I am no developer, but this task is about backend- meaning now there is a *possibility* of larger comments (or comments with multi-byte characters) to be stored on the database, something that was incredibly difficult to handle with the previous structure and required lots and lots of redesign and refactoring on a multi-month effort. A priority was set to this after it reached the top requested feature of the comunity on the yearly survey.

Now, being able to store larger comments doesn't mean you have to- the difficult part was to *allow* them, putting technical or policy restrictions is, once this backend work has been completed, in my opinion- and I want to stress I am no developer-, very very easy compared to the work to make it possible. Frontend can be accommodated, for example, to allow only 255 characters (which can take up to 1000+ bytes). Or it can be stored, but limited or filtered on display (e.g. not counting ipv6 or tags).

Of course my concern isn't the backend possibility to store longer comments, but that it's possible right now to actually enter any text up to 1000 bytes at the ui.

Actually, for what I see, it can be quickly disabled per site by doing: https://en.wikipedia.org/wiki/Special:AbuseFilter/904 Ask an admin to apply it until a more definitive ui fix, balancing all issues (ipv6 addreses, legibility, editor preferences) are taken into account.

Please let's centralize further discussion on T6714, as this is a closed ticket, on future improvements.

Change 192170 abandoned by Brian Wolff:
[WIP] Increase edit summary limit in the UI

https://gerrit.wikimedia.org/r/192170