Page MenuHomePhabricator

Phund Phacility to rid us of callsigns
Closed, InvalidPublic

Description

Callsigns are a Big Deal. They are the reason it's impossible for me to use diffusion in my typical use case i.e. quickly looking at a file I did not checkout: the unpredictability of the URL forces people to use GitHub, where we have an easy URL structure.

3000 $ (https://secure.phabricator.com/T4245#116063) is a very reasonable price to pay for such an obnoxious problem to be eliminated.

Resolved questions in Greg's opinion:

  • who is responsible of such a process:
  • which directors/managers, if any, have any spending authority for such contracts:
  • exact amount of the spending authority;
    • Exact dollar amount irrelevant, @greg has spending authority for over $3000
  • exact process to get specific jobs performed;
    • While anyone is free to interact with upstream Phab as they see fit, for a task to get "prioritization" (ie: funding) from WMF it must be A) a clearly defined specific issue and B) have clear consensus then C) it's is reported upstream and prioritization happens according to Phacility's process (they create a contract with WMF with a timeline etc)
  • whether other people also have spending authority, see e.g. T106130#2115462.
    • Irrelevant as they would defer to @greg whose team owns Phabricator maint and development. <-- a statement of fact from the person who is responsible (in the [[en:Responsibility_assignment_matrix]] sense).

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Luke081515 moved this task from To Triage to Misc on the Phabricator board.Feb 4 2016, 6:19 PM
Restricted Application added subscribers: StudiesWorld, Luke081515. · View Herald TranscriptFeb 4 2016, 6:19 PM
Aklapper triaged this task as Low priority.Feb 9 2016, 10:27 PM

This is going to happen after projects/workboards wrap up and doesn't need to be prioritized externally.

With the current WMF structure, who would be responsible of initiating such a process and/or decide on it? @Wwes perhaps? Do any of the related directors have any spending authority for such small sums (like Lindsey, @mark, Rachel, @RobLa-WMF, @Tfinc, @Tnegrin, @TrevorParscal)? Maybe @Katherine-WMF knows.

@Nemo_bis: That's a good question, though this particular task can probably be closed as Phacility has already implemented this change without us funding it.

Krenair closed this task as Invalid.Mar 13 2016, 11:34 PM
Krenair removed a subscriber: Katherine-WMF.

Agreed with @mmodell, if the change was already implemented, this can be closed. Using invalid as it's no longer valid - neither resolved nor wontfix seem to make much sense in this case. Thanks Phacility.

@Nemo_bis: Frankly, I think Katherine has more important things to be dealing with right now than callsigns. :)

@Nemo_bis: That's a good question, though this particular task can probably be closed as Phacility has already implemented this change without us funding it.

I'm not sure I follow. I looked at https://secure.phabricator.com/T4245#159988 and I looked at T106130#2021535 and both seemed to indicate that there's still work to be done here to make callsigns optional. The part that's "resolved" is that Phacility doesn't require funding to do this work.

My interpretation of this task is that Nemo wants to get rid of callsigns in Wikimedia's installation of Phabricator, meaning this task is still open/unresolved.

Legoktm renamed this task from Fund Phacility to rid us of callsigns to Phund Phacility to rid us of callsigns.Mar 14 2016, 5:15 AM
Nemo_bis reopened this task as Open.Mar 14 2016, 9:41 AM

There is clearly still need of work in this area, and any speedup is appreciated.

It's true that callsigns are optional now, but it's not quite polished. For example, here's a recently created one without a callsign: https://phabricator.wikimedia.org/diffusion/1873/. A few issues I spotted when I needed to look at it:

  • The URL has just the number (where a callsign would otherwise be)
  • It's impossible to browse directly to the repository from the search box (you can use the callsign for this for repos that have it)
  • It's difficult to link to a single commit if you need to disambiguate the repository (the syntax is apparently R1873:33dffa90d7a9, instead of the nicer rESAL33dffa90d7a9)
greg closed this task as Invalid.Mar 14 2016, 3:31 PM
greg removed subscribers: RobLa-WMF, mark, TrevorParscal and 3 others.

With the current WMF structure, who would be responsible of initiating such a process and/or decide on it?

For the record, please do not cc multiple unrelated engineering directors on tasks like this. It is not help and only spams them. The appropriate people are watching this task that have the requisite amount of spending authority (iow: me). I have removed them now to save their bugmail.

This task should be closed as stated by both @Krenair and @mmodell (I'm doing so with this comment). Any additional issues (as @matmarex outlines) should be separate tasks so that we can figure out what is still actually needed in a clean way to then propose upstream. Thanks for the start of that, @matmarex.

@mmodell That doesn't seem to work for all repositories, e.g. https://phabricator.wikimedia.org/r/project/mediawiki/extensions/UploadsLink/ is a 404. ...maybe because that repo has no callsign? :P

Nemo_bis reopened this task as Open.EditedMar 14 2016, 4:59 PM

This report is very clear and does not need further closures; specific issues are already handled in specific reports. The reason I added more ccs was also extremely clear from my comment as well, but we can also make the reason clearer by rephrasing the subject, for instance "Set up a process to fund Phacility to complete essential fixes for us, like callsigns".

I agree that reducing unnecessary bugmail is a good goal; to this purpose I propose to avoid posting unconstructive comments like some of those I saw above.

Greg, the issue has already been pointed to your department multiple times, no need to pretend you had to be contacted before something else could be done. The answer I got was always that no department/sub-department was clearly (willing to be) in charge of this. Now, there are only two alternatives:

  • you take responsibility of this process,
  • you don't and hence you avoid acting on this report.

P.s.: Sorry for any edit conflict or unnecessary change automatically made by phabricator with my description edit.

Aklapper added a subscriber: Qgil.Mar 14 2016, 5:02 PM
greg closed this task as Invalid.Mar 14 2016, 5:06 PM

This report is very clear and does not need further closures; specific issues are already handled in specific reports. The reason I added more ccs was also extremely clear from my comment as well, but we can also make the reason clearer by rephrasing the subject, for instance "Set up a process to fund Phacility to complete essential fixes for us, like callsigns".
I agree that reducing unnecessary bugmail is a good goal; to this purpose I propose to avoid posting unconstructive comments like some of those I saw above.
Greg, the issue has already been pointed to your department multiple times, no need to pretend you had to be contacted before something else could be done. The answer I got was always that no department/sub-department was clearly (willing to be) in charge of this. Now, there are only two alternatives:

  • you take responsibility of this process,
  • you don't and hence you avoid acting on this report.

I did and it was/is being worked on without the need of funding, as stated by Evan himself. Your statements of fact are wrong. And your premise of your statements on that talk page are also wrong and needlessly pessimistic, much like most of your communication, which is why I choose to selectively communicate with you.

The underlying non-pessimistic goal of this task (not needing callsigns in Phabricator) is not being avoided. It is being worked on by both upstream and people in RelEng. Again, please file specific needed actions as this specific task will not move forward.

Nemo_bis reopened this task as Open.Mar 14 2016, 5:08 PM
Nemo_bis updated the task description. (Show Details)
Nemo_bis added subscribers: Wwes, Tfinc, Tnegrin and 3 others.
greg closed this task as Invalid.Mar 14 2016, 5:09 PM
greg removed subscribers: mark, TrevorParscal, Tnegrin and 2 others.

Nemo, please stop adding unrelated engineering directors to this task. This is the second time I have asked you. You are not winning supporters with your actions.

greg updated the task description. (Show Details)Mar 14 2016, 5:09 PM
greg removed a subscriber: RobLa-WMF.
Nemo_bis added a comment.EditedMar 14 2016, 5:10 PM

This is not a popularity contest, Greg, and as you pretend to be aware of how Phabricator works you should know that I'm not the one who added subscribers (cf. known bugs T76993, T96464).

Nemo_bis reopened this task as Open.Mar 14 2016, 5:12 PM
Nemo_bis updated the task description. (Show Details)
Nemo_bis updated the task description. (Show Details)
greg added a comment.Mar 14 2016, 5:12 PM

You did by editing the task description, potentially unintentionally: https://phabricator.wikimedia.org/T106130#2119014 Your comment about a popularity contest is non sequitor (I don't see how any of my actions/statements indicate I am participating in a popularity contest).

greg closed this task as Invalid.Mar 14 2016, 5:15 PM
greg lowered the priority of this task from Low to Lowest.
greg updated the task description. (Show Details)
Nemo_bis reopened this task as Open.Mar 14 2016, 5:16 PM
Nemo_bis raised the priority of this task from Lowest to Medium.
Nemo_bis updated the task description. (Show Details)
greg updated the task description. (Show Details)Mar 14 2016, 5:18 PM
greg updated the task description. (Show Details)

Edit warning is not going to get this done faster.

My commend above (T106130#2118685) outlines a way to link directly to a repository. We also support several other patterns in the url as follows:

Link to a file:

  • /r/browse/${project};${branch};${file}

Link to a branch:

  • /r/branch/${project};${branch}

Link to a commit:

Although funding phacility to promote fixes is something I wholeheartedly agree with, this particular issue is already addressed. @Nemo_bis: What remains to be done here beyond what we already support?

Nemo_bis updated the task description. (Show Details)EditedMar 14 2016, 5:22 PM

Edit warning is not going to get this done faster.

I agree; thanks for having refrained from unnecessarily rollbacking parts of the report. The task description is improving the wiki way, I like it. Let's continue!

Nemo_bis updated the task description. (Show Details)Mar 14 2016, 5:26 PM
Nemo_bis updated the task description. (Show Details)
Aklapper added a comment.EditedMar 14 2016, 5:37 PM

T106130#2119040 asks to avoid statements without references, T106130#2118486 asks to not subscribe uninvolved people to this task, and T106130#2119005 asks for filing specific needed actions (as separate tasks).

To stress again what's been written in T106130#2119108 :

this particular issue is already addressed.
What remains to be done here beyond what we already support?

@Nemo_bis: Could you answer that question, as you seem to strongly disagree with closing this task?
If there are remaining items, T106130#2119005 asks for filing specific needed actions (as separate tasks).

Adding a comment suggesting the status change and convincing reasons for it (emphasis by me) is recommended by the Etiquette.

greg updated the task description. (Show Details)Mar 14 2016, 5:42 PM

It's true that callsigns are optional now, but it's not quite polished. For example, here's a recently created one without a callsign: https://phabricator.wikimedia.org/diffusion/1873/. A few issues I spotted when I needed to look at it:

  • The URL has just the number (where a callsign would otherwise be)

This is addressed by our /r/project/x/y urls

  • It's impossible to browse directly to the repository from the search box (you can use the callsign for this for repos that have it)

type 'r operations-mediawiki-config' into the search box, it'll take you directly to the repo.

This should work, but apparently there is some bug because it gives a 404: /r/revision/operations/mediawiki/config;fcb6aef9d415

@Nemo_bis: Could you answer T106130#2119206 please? Thanks in advance!

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 27 2016, 8:02 AM
Aklapper closed this task as Invalid.May 4 2016, 8:18 AM

No reply in a week - closing again.
If something has not been addressed in T106130#2119339 please specifically point out in a comment. Also see T106130#2119005. Thanks.

Nemo_bis reopened this task as Open.May 14 2016, 3:57 PM

See blockers of T108864

Regarding those two blockers,

  • T129447#2140932 says that we are going to maintain that manually until Gerrit is dead.
  • For T111887, paladox seems to work on that functionality in D233.

Hence I cannot follow the argumentation why those two tasks would require to keep this task open. Proposing to decline or invalidate.

Callsigns are dead. Other issues are tracked in other tasks. This one seems no longer valid to me.

Aklapper closed this task as Invalid.May 22 2016, 12:47 PM

No reply to T106130#2295085 within a week, hence closing again.

Nemo_bis reopened this task as Open.May 22 2016, 1:00 PM

Callsigns are definitely not dead, or how would you explain the existence of an URL like https://phabricator.wikimedia.org/diffusion/ESAL/ ?

Callsigns are definitely not dead, or how would you explain the existence of an URL like https://phabricator.wikimedia.org/diffusion/ESAL/ ?

To cite your original bug report:

Callsigns are a Big Deal. They are the reason it's impossible for me to use diffusion in my typical use case i.e. quickly looking at a file I did not checkout: the unpredictability of the URL forces people to use GitHub, where we have an easy URL structure.

In other words, the fact that the current canonical URL is still https://phabricator.wikimedia.org/diffusion/ESAL/ is irrelevant. The repository can be linked via https://phabricator.wikimedia.org/r/project/mediawiki/extensions/SandboxLink , and that was what the bug was about.

@Nemo_bis callsigns are optional meaning for example if you doint add a callsign you can only access the repo by it's number which it generates.

For example see mw core. https://phabricator.wikimedia.org/diffusion/MW/manage/uris/

You can access it by http://phabricator.wikimedia.org/diffusion/19/

or http://phabricator.wikimedia.org/diffusion/MW/

matmarex removed a subscriber: matmarex.May 22 2016, 3:21 PM

Callsigns mere existence isn't harming anyone. They allow me to write this:

{rMW}

and produce this link to the repository:

rMW MediaWiki

Yet you can still go to /r/project/mediawiki/core if you prefer the old way. You can even see the mapping at /r/

Human-readable URLs are supported now but they should become default, callsigns should redirect to them, not vice versa.

Qgil removed a subscriber: Qgil.May 28 2016, 9:22 PM

@Ricordisamoa: Feel free to file a separate feature request, as your wish is not in scope for this task.

Aklapper closed this task as Invalid.May 29 2016, 8:33 PM

Closing as invalid, as a reply to T106130#2315957 was given in T106130#2316001 and T106130#2316289

@Ricordisamoa: Feel free to file a separate feature request, as your wish is not in scope for this task.

I've just filed T137036: Make repository URIs verbose by default