Make PhabricatorDifferentialRevisionTestDataGenerator::generateDescription() have more than one sentence

Seems nice! Feel free to update.

In D25872#27180, @valerio.bozzolan wrote:

P.S. Uh, I noticed that arc work also has a --start parameter! I documented a bit the expected behavior in the task T15993.

So that parameter is currently not supported for tasks, maybe relevant for the patch author:

$ arc work --start stable T15993
 NEW BRANCH  Creating new branch "T15993-support-for-arc-work-t12345-(workontask-workflow)" from "master".
 BRANCH  Checking out branch "T15993-support-for-arc-work-t12345-(workontask-workflow)".

So you see that from "master" that means we are not supporting --start, I guess.

If we cannot add support to that, we can add another cute TODO-exception for this corner case I guess (and create another task I guess)

Partial review, will conclude (I hope asd)

git rebase master

Sigh, I swear I grep'ed for isArray before but I was in a parallel CamelCase world in that moment

Plus, making the file editable by the author is the cure of T15814, so, moving that as parent task.

If we allow authors to destroy their images, we should also avoid 404 errors on them. So, the new subtask T16074.

Thaanks

(I just sorted the description to have the same order of the preview so it was easier for me to review)

Love this, thanks

In D25872#27180, @valerio.bozzolan wrote:

P.S. Uh, I noticed that arc work also has a --start parameter! I documented a bit the expected behavior in the task T15993.

So that parameter is currently not supported for tasks, maybe relevant for the patch author:

$ arc work --start stable T15993
 NEW BRANCH  Creating new branch "T15993-support-for-arc-work-t12345-(workontask-workflow)" from "master".
 BRANCH  Checking out branch "T15993-support-for-arc-work-t12345-(workontask-workflow)".

So you see that from "master" that means we are not supporting --start, I guess.

If we cannot add support to that, we can add another cute TODO-exception for this corner case I guess (and create another task I guess)

In D25872#27178, @valerio.bozzolan wrote:

Tested for T15100 and T15993 and I'm a bit surprised to obtain, this very long branch with commas and square brackets (and just the closing bracket? uhm)

T15100-feature-request]-option-to-measure-wip-limits-based-on-card-count-instead-of-points,-to-more-closely-adhere-to-kanban-standards

and this with round brackets (that is not Bash friendly for the git autocomplete):

T15993-support-for-arc-work-t12345-(workontask-workflow)

Probably here we should normalize a bit more these branch names. To do it, I see that Phorge already has a "normalize" method that does great things, but unfortunately it's not available in Arcanist (we cannot call it, or we create a circular dependency)...

https://we.phorge.it/source/phorge/browse/master/src/infrastructure/util/PhabricatorSlug.php

What do you think about? Should we import a very minimal "ArcanistSlug" class? And now/then having PhabricatorSlug extending that? (to give 100% backward compatibility but uniform code)

I'm a bit unsure. Thanks for opinions.

remove some unneeded brackets in regex

looool double-slam-accept

Right...hmm, now I also wonder. :)
Should probably be iPhone|iPod|Android.*(Chrome/[.0-9]* Mobile|Mobile.*Firefox/[.0-9]*) (it's still that Firefox on Android has that Android string first, thus the brackets).

or with slash and version:

We shall keep version. There"s a good number of user-agent strings out there concatenating random browser names while not being these browsers.

git rebase master

git rebase master

My grep loves this

My grep loves this

e.g. https://regex101.com/r/PDyAGh/1 (then the slash, or the slash and the version - but that is)

There is something wrong now nearby the |((Chrome, that should be enclosed by pipes and just one bracket, like an hamburger of pipes, like @stuff|(Chromestuff)|(Firefox stuff)@0

wrap long string to make lint happy

but in Firefox seems easier, we can just match "Mobile.*Firefox" probably

@A_smart_kitten you are super-super-welcome if you create another parent task like this https://web.archive.org/web/20250218071010/https://secure.phabricator.com/T12486 so " Search exclude-by-tag doesn't work consistently with subprojects" - since I completely agree on your point but I'm unsure how to manage it, so here T15828 we become just one of your sub-tasks.

Per https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/User-Agent/Firefox (and other pages like https://www.whatismybrowser.com/guides/the-latest-user-agent/firefox ), the current regex check in Phorge requiring the string Chrome won't even try to match Firefox browsers on mobile (e.g. Mozilla/5.0 (Android 15; Mobile; rv:138.0) Gecko/138.0 Firefox/138.0).

• 🔶 this task (T15828) is not reporting a real-world thing about this use with sub-projects

FWIW, my use case from today in terms of sub-projects was attempting to search tasks on Wikimedia Phabricator that were tagged with either #MediaWiki-Recent-changes or #Edit-Review-Improvements (or a subproject thereof).

Triaging a bit more than "Wishlist" and a bit less than "Normal" since a prototype is actionable but we still lived years without this... so, "Low".

OK hackers, thanks for stimulating a follow-up. I've studied this a bit and I have a more clear opinion. Let's write some notes down.

Reverting rARC29575b4f91876bf0a95739eba50f792e2aa78c0c and rP6619fef2ff977ea81092b970e58abbb33e78f644 makes Phorge throw errors again:
Firefox says This page is in Quirks Mode. Page layout may be impacted.,
Chromium says net::ERR_CONTENT_DECODING_FAILED 200 (OK)),
both because the deprecation warning is added before the usual HTML header created by AphrontPageView, as curl shows:

[acko@foo phorge (master *$|u=)]$ curl 'http://phorge.localhost'
<br />
<b>Deprecated</b>:  Constant E_STRICT is deprecated in <b>/var/www/html/phorge/phorge/support/startup/PhabricatorStartup.php</b> on line <b>391</b><br />
<!DOCTYPE html><html data-developer-mode="1"><head><meta charset="UTF-8" /><title>Home</title><meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=yes" /><link rel="mask-icon" color="#3D4B67" [...]

We don't end up calling PhutilErrorHandler::handleError() or PhutilErrorLog::onError() or PhutilSystem::writeStderr() here.

Gonna boldly call it a bug, given that I was about to file an upstream bug report for https://phabricator.wikimedia.org/T386830 before I came across this task :)

P.S. Uh, I noticed that arc work also has a --start parameter! I documented a bit the expected behavior in the task T15993.

Tested for T15100 and T15993 and I'm a bit surprised to obtain, this very long branch with commas and square brackets (and just the closing bracket? uhm)

• arc lint
• arc unit
• fix a couple of id($api) and just use $api

Do you know for sure (did Fabio explicitly say so)

seems manually uploaded by an user, but it's not

This is different than T15814: Files: reduce number of orphan transformed files