Page MenuHomePhabricator

Narrow scope of MediaWiki-Database workboard
Closed, ResolvedPublic

Description

This tag has a long and complicated historically. It predates our use of Phabricator (it imported from Bugzilla), and therefore also predates our use of workboards and (mostly) predates the decentralised triaging of incoming tasks on a per-project or per-team basis.

Back then it was all a shared pile in Bugzilla where were all manage it collectively as a single engineering department, with the components primarily serving the needs of end-users who would reporting issues and express the area with some keywords and a (single) sub component of "MediaWiki".

The "Database" component would then be used for whenever something needed maintenance on WMF db servers, or when a third-party site-admin encountered an issue setting up or migrating their database, or when end-users encounter internal server errors that relate to a database in some way. Anything that had some relation to a database.

I don't think this is useful anymore in this form. It doesn't serve any of the relevant audiences well.

  • For end-users reporting an issue with a feature they tried to use, the chances of a product owner finding the bug report here are next to nil.
  • For issues that are correctly filed under their respective components, but co-tagged "MediaWiki-Database" get moved to "Usage problem". I don't know if this has value to anyone. I suspect it doesn't, in the same way that tagging all issues relating to "MediaWiki-PHP" or "MediaWiki-JavaScript" wouldn't be useful, either. If there is interest in a generic tag, not bounded by the scope of MediaWiki core, for database errors, then perhaps we should create a generic "Database error" tag for that.
  • For bugs and proposals for core schema changes, we have Schema-change already.

What remains is issues with the Wikimedia-Rdbms library, which is what the majority of open issues on this workboard are currently about.

I propose to:

  • Hide "Schema change" column, untag issues and ensure Schema-change is present instead, as well as at least one relevant MediaWiki-prefixed component tag (or MediaWiki-General).
  • Hide "Usage problem" column. After a while, untag or migrate to a new generic tag if there's interest.
  • Rename project to Wikimedia-Rdbms.

Thoughts?

Event Timeline

Krinkle created this task.Jul 18 2019, 1:00 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 18 2019, 1:00 AM
Anomie added a project: DBA.
Anomie added a subscriber: Anomie.

I'm not sure about the Schema-change part. That tag claims to be about actual schema changes. Glancing through the tasks currently in the schema change column of Wikimedia-Rdbms, it seems a combination of actual schema changes, requests for maintenance scripts related to schema changes, and bugs in the updater when applying schema changes.

Other than that, sure. But let's also ping the DBAs in case they have any input.

So, from my side, this is the way I read those tags:

Schema-change is where a discussion about an upcoming schema change might happen (it can also happen with Wikimedia-Rdbms, in fact, I have seen that happening more often with that tag lately).
Blocked-on-schema-change is when a change is ready to happen and is blocked on DBAs and depends on us to be able to release something (ie: adding an index or a new column).
We have also had schema changes which are just clean up, and are not blocking anything (ie: dropping a non used column). I tend to remove the Blocked-on-schema-change tag from there and just tag DBA as it is just backlog for us and nothing is really being blocked.

I don't personally mind much about the process with Schema-change and Wikimedia-Rdbms for the schema changes discussions and then once it is ready to be sent to the DBAs keep following the schema change procedure that will get the schema change template and Blocked-on-schema-change tag.

I'm not sure about the Schema-change part.

Thanks, I'm not actually very familiar with the Phabricator workflow used by others for schema changes. I'll defer to you and others on what's current practice and what would work best/better for you (plural).

Glancing through the tasks currently in the schema change column of #mediawiki-database, it seems a combination of actual schema changes, requests for maintenance scripts related to schema changes, and bugs in the updater when applying schema changes.

Would using MediaWiki-Maintenance-scripts and/or MediaWiki-Installer be a more suitable place for those task two kinds of tasks? I'm also hoping to generally push tasks more towards feature-based areas. So for example an issue with a maintenance script or db-updater for a ResourceLoader database table would, I think, be best benefit the reporter, if it were organised under MediaWiki-ResourceLoader and not Maintenance-scripts or Installer.

Krinkle triaged this task as Normal priority.Jul 18 2019, 2:36 PM
jcrespo added a subscriber: jcrespo.EditedJul 18 2019, 2:43 PM

I personally don't have any opinion about Wikimedia-Rdbms I don't interact with it or need it or I am not subscribed to it. It is nice that we are pinged here because of the obvious connection with DBA (thanks!) but I will let any users or potential users decide its usefulness (redefine it, rename it, reorganize it, delete it, merge it, etc.). I believe it was useful in the past because there was no official owner to the RDBMS, but I think that is no longer the case.

The only semi-offtopic proposal I made was to create #query-optimization as a yellow tag (name could be something else) which may cover some of those, and would be handled by #DBAs (infra solution) and the corresponding codebase owner (code solution). But that is a separate issue.

Would using MediaWiki-Maintenance-scripts and/or MediaWiki-Installer be a more suitable place for those task two kinds of tasks?

Yes, probably.

I'm also hoping to generally push tasks more towards feature-based areas. So for example an issue with a maintenance script or db-updater for a ResourceLoader database table would, I think, be best benefit the reporter, if it were organised under MediaWiki-ResourceLoader and not Maintenance-scripts or Installer.

Since Phab supports multiple tags on a task, depending on the details of the bug I might tag it with both. Particularly since a person searching for it might not know it's an RL table but does know it affects MediaWiki-Installer.

From a bug filer perspective, Wikimedia-Rdbms is really not a great project name. We usually don't prefix library phabricator projects with Wikimedia- (most Wikimedia- projects are Wikimedia specific, whereas libraries are the exact opposite), and I don't think most people will equate Rdbms == Database issues. Calling it just Database might be a little too general though.

The other changes look good, but I'm also not an active user of this project.

[..], and I don't think most people will equate Rdbms == Database issues.

Hm.. did you mean this as a good thing or a bad thing? I ask because, that which most people would classify as "Database issues", I think, would be out of scope for this tag. Rather focussing on issues with, and ideas for, the wikimedia/rdbms library. The label "Database" would indeed be too generic and also isn't what the library is called (it's called wikimedia/rdbms).

Our other libraries have fairly noun-able names that are unlikely to be confused with a general technical term when written down (at-ease, WrappedString, …). But, the "rdbms" library seems hard or awkward to refer to as "rdbms". I've generally referred to it as "Wikimedia rdbms" or "lib rdbms". What should we call the Phabricator project? Or should we come up with a new name and use that for both the Phabricator workboard and the Composer package? (but as PHP namespace?)

kchapman assigned this task to Krinkle.Jul 22 2019, 7:55 PM
kchapman moved this task from Inbox to Doing on the Performance-Team board.
Krinkle updated the task description. (Show Details)Jul 23 2019, 4:03 PM

I've renamed the project from MediaWiki-Database to Wikimedia-Rdbms (keeping an alias for compat). I'll leave this task open for better suggestions.

Krinkle closed this task as Resolved.Aug 2 2019, 2:38 PM

@Aklapper I noticed you renamed the workboard from Wikimedia-Rdbms to Mediawiki-Rdbms. I can speculate about reasons, but could you briefly explain the reason here for the record?

Krinkle reopened this task as Open.Aug 20 2019, 6:37 PM
Aklapper added a comment.EditedAug 20 2019, 9:32 PM

@Krinkle: I don't know what "Wikimedia-Rdbms" is supposed to be so I expected it to be a typo that I fixed, but now I saw T228360#5358106... Isn't that tag about the MediaWiki Core codebase, as its project description says? If it is not, then what is that Rdbms which is on Wikimedia servers but not in MediaWiki Core?

@Aklapper It is indeed common to use "MediaWiki" to refer to the general and re-usable software and "Wikimedia" for WMF-specific things. However, this mainly applies to social and organisational concepts. For the software libraries we maintain, it is (unfortunately) the opposite.

The various open-source software libraries (doc link, distro link) that we maintain and publish are published as "Wikimedia". The idea here is to emphasise that these are not merely part of MediaWiki core, but re-usable more widely. Libraries such as wikimedia/cdb, wikimedia/utfnormal, wikimedia/WrappedString, and many more. The rdbms is also one of those. Our Phabricator convention for the "MediaWiki-" prefix is primarily for components part of core, not for separate libraries. Those have their own component (e.g. WrappedString), where we omit the "Wikimedia-" prefix presumably because the remaining part is clear and unambiguous enough.

However, given the generic nature of the abbreviation "rdbms" I named the Phabricator project "Wikimedia-Rdbms" instead.

I've renamed it back because it's not a general MediaWiki core components, and not organised in the "MediaWiki\" namespace in PHP. It is wikimedia/rdbms. But, as the previous comment from mine, I am open to better names for the Phabricator project :)

Krinkle closed this task as Resolved.Aug 25 2019, 9:39 PM
Krinkle removed Krinkle as the assignee of this task.
Krinkle edited projects, added Performance-Team (Radar); removed Performance-Team.