@epriestley : our current phabricator version is c46be2a70b4db72d61e76690ef095384de2c3f91 that was landed on 04/13, will there be any issues if we directly cherry pick the recent two versions without pulling any other changes?
rP51073b972ece: Try to route cluster writes to nodes which won't need to synchronize first.Wed, Oct 17, 3:08 PM
rPbc6c8c0e93a7: Explicitly shuffle nodes before selecting one for cluster sync.

Yeah, we still run into the same problem from time to time:
error: the patch applies to 'hadoop-scala/lib/driven-plugin-1.3.6-hosted-ga-11.jar' (49f50831fe1109b164f56c8e823132aa5f5171c9), which does not match the current contents.

• remove the change made by accident

When I put var_dump() in other parts of the code, I can see the output from /var/log/apache/error.log, but just can't see any output for the ones I mentioned above.

It looks like "git push" in DrydockLandRepositoryOperation.php doesn't get executed.
I put some var_dump as the following, and click "Land Revision", but no related log printed out.

Okay, I am able to expand further by adding more requests. Thanks for the explaining!

This looks much better! Thanks!

This works for me now! Thanks!

Thank you!

In D14823#168810, @epriestley wrote:

Thanks! I added you to Blessed Committers, so you should be able to land this yourself.

(The project page also has some instructions on how to get access configured, now.)

Updated based on Evan's comments.

Thanks @epriestley! I'll try it out.

It looks like it counts the total working copies. I thought the limit is for every single repo: when I set the the limit to be 5, I expect that every single repo can have 5 copies at most. This is not scalable: when more and more repos get created, we have to adjust the limit.

Also why can't a new lease get another resource when previous lease holds a resource? I set the limit of the working copy to be 5, so there should be enough resources available to be used.

Thanks for taking care of this!

I tested this feature and noticed that the browse button beside "Onto Branch" was not clickable unless I removed the pre-populated default branch.

Thanks for thinking through all of these! Let me know if there is anything I can help with.

Ok, got it. Do you think it's reasonable to search using a package name?

You are right for the cases you described. But the case I mentinoed is that /src/infrastructure/PhabricatorEditor.php doesn't exist in both Arcanist and libutil.

Thanks for the workaround!

In T9967#148569, @epriestley wrote:

Do you have the public key (or the private key), or do you just know which user has a compromised key but not know which key is compromised?

That is, which of these commands would you be able to run if they were available?

./bin/auth revoke-public-key /path/to/compromised_public_key.pub
./bin/auth revoke-private-key /path/to/compromised_private_key.key
./bin/auth revoke-all-keys-for-user username

In T9964#148566, @epriestley wrote:

I can't reproduce that. Here's a search using "Path", which seems to work correctly:

Can you give me more details about how to reproduce the issue you're seeing?

You might already know, but I noticed that the owners search is broken if I use "path" instead of "Repositories" to query. Also it would be great if we can use the package name to search.

Yeah, I upgraded my dev instance to Head which doesn't have this issue. Thanks!

Indeed, it works after I turned it back on. Thanks!

I tested the change and this partially works, now I see the email shows like the following:
INLINE COMMENTS

urls.py:5 test inline comments.

Okay, it turned out he installed Arcanist using brew, not sure why it caused the difference though. I have updated our wiki page asking people to install Arcanist by following the instruction at https://secure.phabricator.com/book/phabricator/article/arcanist/.

His version:

If I click any of the following tasks:

The new commits got stuck at importing:

If I go look at the task, I see this:

@epriestley, thanks for consolidating my request into this task! Some comments: a person could be an owner of multiple packages, it would be better to indicate all files with their package names instead of only indicate the files you are an owner of; We actually don't need to put the package name on each line, we can group the files by package and put the package name to each group. One benefit of indicating all files with package names is everybody see the same, there will be less confusion (in most cases we can assume everybody knows if s/he is an owner of a package).

thanks!

Good catch! Thanks!!!

EX10301:pinboard nickz$ arc diff --trace
libphutil loaded from '/Users/nickz/Arcanist/libphutil/src'.
arcanist loaded from '/Users/nickz/Arcanist/arcanist/src'.
Config: Reading user configuration file "/Users/nickz/.arcrc"...
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: Reading .arcconfig from "/Users/nickz/code/pinboard/.arcconfig".
Working Copy: Path "/Users/nickz/code/pinboard" is part of git working copy "/Users/nickz/code/pinboard".
Working Copy: Project root is at "/Users/nickz/code/pinboard".
Config: Did not find local configuration at "/Users/nickz/code/pinboard/.git/arc/config".
Loading phutil library from '/Users/nickz/code/pinboard/.phabricator-libs/affogatolinter'...
Loading phutil library from '/Users/nickz/code/pinboard/.phabricator-libs/owners'...

[0] <conduit> conduit.connect() <bytes = 455>
[1] <http> https://phabricator.pinadmin.com/api/conduit.connect

<<< [1] <http> 1,675,525 us
<<< [0] <conduit> 1,675,896 us

[2] <exec> $ git diff --no-ext-diff --no-textconv --raw 'HEAD' --
[3] <exec> $ git ls-files --others --exclude-standard

<<< [2] <exec> 139,713 us
<<< [3] <exec> 138,967 us

[4] <exec> $ git diff-files --name-only

<<< [4] <exec> 69,617 us

[5] <event> diff.didCollectChanges <listeners = 0>

<<< [5] <event> 54 us

[6] <exec> $ git rev-parse --verify HEAD^

<<< [6] <exec> 29,763 us

[7] <exec> $ git merge-base 'origin/master' HEAD

<<< [7] <exec> 31,620 us

[8] <exec> $ git rev-parse 'HEAD'

<<< [8] <exec> 28,088 us

[9] <exec> $ git log --first-parent --format=medium '955511af274213958dceec8da321a786467ed6bc'..'cd5209c7bf769de9e293afa3b8a90327a28a3d48'

<<< [9] <exec> 31,014 us

[10] <conduit> differential.query() <bytes = 291>
[11] <http> https://phabricator.pinadmin.com/api/differential.query

<<< [11] <http> 1,275,340 us
<<< [10] <conduit> 1,275,577 us

[12] <exec> $ git rev-parse --git-dir

<<< [12] <exec> 6,059 us
You have a saved revision message in '.git/arc/create-message'.
Message begins:

Yes, arc up to date:

after updating to the latest version, I still got the error:

Cool, thanks!

Ah, yeah, I believe that's the issue, I thought the mailing list user doesn't have to be given the read permission specifically. Thanks a lot for looking!

is the following the same or different one?

To us, this happens only when the lint fails. If no lintable change, it seems fine no matter if a unit test gets run or not.

Let me know if you need more information.

We'd like this to be done soon as well. People have been complaining about using callsigns.

Okay, thanks @epriestley!

It would be great if we know the ETA for the fix no matter soon or not soon.

In T7166#95831, @cburroughs wrote:

Is this the same as the herald based replacement for project mentions + email (T6819) ?

Hi Chad, Yes, without this fixed, we are not able to move forward for all tasks which need putting a project to CCs as a condition of the Herald Rule. Yes, it's up to your guys' priority list. But I hope this can be address very soon. Thanks!

@chad, have you found the root cause?

@chad, I am glad you can reproduce it.

Anything I can do to faster the process to fix the bug?

In T7166#94790, @btrahan wrote:

sterling matches a user in remarkup, while #sterling matches a project. Did you verify the sterling in the subscribers section clicks through to the project and not some user also named sterling? (Or said differently, did you type sterling as initially reported (not a bug and probably due to the issue I am describing) or #sterling (a bug)?)

Add myself as a follower.

Thanks Evan!