Page MenuHomePhabricator

Should a deprecated, unmaintained upstream software version deployed on WMF servers still be tagged as #upstream in Phabricator?
Closed, InvalidPublic

Description

Reason: librsvg 2.40-bugs in phabricator are currently reported mostly as upstream, but the C-version of librsvg was depreciated in 2017 (last release 2017, deapreciated 2017, librsvg-developer declares do not use the C-version of librsvg ), and is forever suspended, and bug-reports are closed at librsvg as depreciated. Even @Aklapper wrote in an bug-report: "Please note that 2.40.x is an ancient, unsupported version."

You "cannot" report

  • a open-office-bug in libre-office
  • a sodipodi-bug in inkscape
  • a owncloud-bug in nextcloud
  • a C-only-librsvg 2.40-bug in Rust-only-librsvg 2.50

Yes C-only-librsvg 2.40 and Rust-only-librsvg 2.50 have the name and the same place to report bugs, so it is confusing, but it is imho similar to a fork of a project. You can report problems of the fork in the fork, but not of software already fixed in the fork.

But since librsvg-2.40-bugs won't get fixed anymore, it is the responsibilty of the user (WMF and not librsvg) to fix bug or not, which makes librsvg-2.40 as a part of Wikimedia and not any more an upstream-bug.

I would not actively remove upstream in such tasks, but we might should not add upstream any more to librsvg-2.40-bugs.

The reason why I bring it up on phabricator is because of categorizing tasks in wikimedia-svg-rendering, as suggested in T282740.

I'm not a developer so I maybe missed something and I don't know the meaning of upstream that well.

Event Timeline

Reedy subscribed.

Wikimedia probably aren't going to start "maintaining" abandoned upstream project(s), especially when there are newer versions or viable alternatives.

https://packages.debian.org/buster/librsvg2-2 - 2.44.10-2.1
https://packages.debian.org/bullseye/librsvg2-2 - 2.50.3+dfsg-1

Does this therefore become a none issue when Debian 11 (bullseye) comes out, and more so, when WMF upgrade image scalers etc to it?

JoKalliauer triaged this task as Lowest priority.EditedMay 16 2021, 2:42 PM
JoKalliauer updated the task description. (Show Details)

Wikimedia probably aren't going to start "maintaining" abandoned upstream project(s), especially when there are newer versions or viable alternatives.

Sorry, I wrote it unclear. Of corse wikimedia wont maintain librsvg2.40, it is just a question if "upstream" is the correct word, and if such issues should be marked as upstream or not.

Does this therefore become a none issue when Debian 11 (bullseye) comes out, and more so, when WMF upgrade image scalers etc to it?

If updating librsvg fixes the issue thats the case in 28 task, that is is not a issue any more.

I think it is, as it's still "someone else software" (which is basically what we mean - it's not software Wikimedia write/maintain).

Obviously sitting around expecting "upstream" to fix it isn't going to yield any results (which is the problem here), but for purposes of tracking and categorising, I think it's still right.

From the Upstream description

This tag could also be used in combination with the "stalled" status.

From the Upstream description

This tag could also be used in combination with the "stalled" status.

ie the tags and status should match reality. If it's not going to be fixed, mark it upstream and stalled... And wait for tasks for upgrading the OS to Bullseye to tag it as a subtask.

JoKalliauer claimed this task.

According to wikimedia-svg-rendering-table only 2 librsvg-tasks of ~48 librsvg-tasks is set to stalled, so this means the remaining 46 librsvg-tasks should set according to T282740 also to stalled?

Aklapper changed the task status from Resolved to Invalid.May 16 2021, 5:09 PM

I agree (plus big thanks for looking into this!). :)

I would not actively remove upstream in such tasks, but we might should not add upstream any more to librsvg-2.40-bugs.

For the records: Ideally, people first try to reproduce an issue in a recent, supported librsvg version. If it is still an issue, a report should be filed upstream.
If it is not an issue, then it might have either been already fixed in the upstream codebase over the last months/years (the workboard at https://phabricator.wikimedia.org/tag/upstream/ has a "Patch merged upstream" column) or it is really a downstream (local configuration changes) issue...

(PS: Please bring up such questions in support places - Phabricator tickets are for actionable bug reports, enhancement requests, tasks. Thanks!)

Reedy renamed this task from Is a deaprecated software which is forever suspended, still upstream? to Is a deprecated software which is forever suspended, still upstream?.May 16 2021, 5:53 PM
Aklapper renamed this task from Is a deprecated software which is forever suspended, still upstream? to Should a deprecated, unmaintained upstream software version deployed on WMF servers still be tagged as #upstream in Phabricator?.May 17 2021, 7:18 AM