I have a feeling both of these can be blamed back to me...

In T15178#4404, @dcog wrote:

@avivey

What is the criteria for determining the intentions of various accounts and banning?

Are there any accounts that hinder notifications and general progress intentionally or is it hard to tell?

Since the context of these changes is all localized here, I think it's reasonable to use the short names (T1234), because we expect most users will see it in the context of this site. I just find the full addresses to be harder to read (I need to stop and actually read the URI to understand if this is an "internal" or "external" link).

@dcog why do you think this is a bad question?

@dcog hmm?

I agree with this, but I think we should let this wait for broader discussion - there maybe good counter-arguments.

In D25092#2806, @valerio.bozzolan wrote:

remote: This push was rejected by Herald push rule H8.
remote:     Change: commit/
remote:       Rule: Guard Arcanist Repo with Blessed Committers
remote:     Reason: Commit is not approved by Blessed Committers
remote: Transcript: https://we.phorge.it/herald/transcript/4967/

https://we.phorge.it/herald/transcript/4967/

Related: https://secure.phabricator.com/T3887 (but I think it doesn't actually work any more?)
https://secure.phabricator.com/w/changelog/2013_09_september/: "Audio can now be embedded in Remarkup"

• fix

(I haven't seen @20after4 for a while now. Also @0).

• change language and replace "status" with "isHidden"
• celerify

Thanks - this logic could use some more love, as you say.

Looks like that's because PhabricatorBadgesSearchConduitAPIMethod extends PhabricatorSearchEngineAPIMethod, and TransactionSearchConduitAPIMethod extends ConduitAPIMethod directly...

In T15047#3538, @valerio.bozzolan wrote:

Maybe unrelated. Can we - right now - update the coding standard to avoid $a = array() (that is a tremendous old approach) to just adopt $a = []? Note that the short version was introduced in PHP 5.4, that already is the minimum version right now. I'm talking about this document:

https://we.phorge.it/book/contrib/article/php_coding_standards/

(If I remember correctly the rules we set for rP, you should be able to arc land all of these now)

This change should include updating the installation instructions (in the manual and in the error message in PhabricatorExcelExportFormat)

1. Is this even used?
2. Looks like the file is currently in Windows mode; can you please split this to 2 diffs, or just keep the original line-ending?

The concept we're aiming for is "Extension Store" - Core to be minimal,. and everything else to be an optional install, with an "app store" somewhere here, and making installing extensions easy.

In D25061#2018, @valerio.bozzolan wrote:

Thanks!

It seems I'm not able to land since I'm not a Blessed Committers sigh.

I was not able to conclude the "arc diff" since it tries to connect to an unexisting database owned by root.

I don't see this error - can you provide reproduction instructions?

That's usually a sign that the Daemons are in some trouble. Go to the Daemons app and see their status and task status.

For completeness: The security breaches mentioned in the security guidance task are all about exposing an existing file that the attacker has new view access to; This flow is only relevant to explicitly uploading a new file, so it doesn't have the same security implications.

The change should also include updating the installation instructions, and a ticket.

https://secure.phabricator.com/T9782 suggests it should be using the "custom fields" interface and eventually fizzles out.

Rebased and run unit tests again

(On a broader theme, this code should probably move into rP, right? Is there any use-case for arcanist directly making calls to 3rd party services?)

running celerity map should just fix it. I'll take a look.

I'm good with this, but we have a policy of "no landed diffs w/o tickets", so please create one before landing.

We should connect this script (scripts/celerity/*.php) into bin/celerity.

The original discussion in T12144 is kinda convincing to me, although it's mostly convinces me that the term "milestone" doesn't match these objects.

can we keep the actual deletion as optional for a very long time/forever, and at the same time not create the database for new installs?
that will allow installs to backup/export their logs even if they miss the deprecation warning.

also link to the updated Twitch docs about the auth API?

@k__nard: do you mind submitting the diffs as revisions using arc diff?

Looks like https://secure.phabricator.com/D21718 explicitly changed to always remove --quiet, so unless there's a new argument for it, this change is redundant.

I've ran this locally, and it looks the same to me (Chrome on Windows).