One concern I have with this is that the largest sequential milestone may not be the "current" milestone. If you're currently in Sprint 4, someone may reasonably create Sprint 5 before Sprint 4 concludes.

Per above, this is working as intended. I'm open to implementing "Copy Columns from <Previous Milestone>" if anyone actually wants that, but it seems like I may have just made it up. Feel free to file a new task if you'd like to see it.

Yep, that looks good to me.

Just for my own understanding:

For (2), the specific problem is that there's no way to look up the milestone PHID, right? If you have the PHID I believe maniphest.search lets you find tasks tagged with a particular milestone:

@avivey my local repo does not have the metadata file but some of the commits do have the git-svn-id in the commit message. I think once we make enough commits on this repo this problem should probably go away but this particular repo doesn't receive commits very often. I would rather not fork arc.

@jcarrillo7: Does your local repo has a .git/svn/.metadata file? We're short on actual data for this use-case.
Alternatively, can you fork arcanist for your install?

When I try to make E1211 recurring (see screenshot below), I get

See also T4144#175505

Please read and follow the guidelines in Contributing Feature Requests, this should have been at the top of the Feature Request form (see below). Unfortunately we're not able to take requests that don't state a root problem.

n/m, I see this was fixed today with https://secure.phabricator.com/rP1f2306999bb599bcedc0c4bfff2f2b3aade58630

I think this should be fixed by D17146, which landed a few hours ago. Presumably you're running some ancient stone-age version of Phabricator that's 6 or more hours old?

P.S. I love the new categories, they're my favorite improvement in the last year!

I think I got all of these, but yell if you catch any more.

We keep hitting the same thing where a conduit reports an svn commit for "sourceControlBaseRevision" on a repo that is git (was originally svn and was transferred to git).

This should do it:

Yep, here is the default value on all the installs of PHP I've done from source:

Am glad to get ahead of it. What's the exact incantation we need to put into our php.ini?

(After T12071 we will almost certainly require "E", so you could get ahead of that now.)

Actually, it looks like PHP defaults to "EGPCS" but ships with config files that use "GPCS" (??? why would you do this ???), so this is probably not something that got changed or configured intentionally or accidentally.

Perfect, thanks! That's what I expected, so D17148 should resolve this. Alternatively, setting that value to "EGPCS" (without upgrading, just restarting the daemons) should also resolve this.

I believe this is now fixed at HEAD of master. You should be able to pick up the change with arc upgrade now (if you run master) or in about 36 hours (if you run stable).

While I'm chasing this down, can you show me the output of this command?

This is an unintended side effect of D17100 but resolution isn't straightforward.

This is D17122 interacting with some extremely high-quality code in arc.

This is far afield from an actionable bug report.

Yeah, There is no postfix, but my distro (SUSE Linux Enterprise) sendmail is a postfix variant. I have to match your sendmail config to my postfix. The last part was done with the help of canonical which is wrong way to do it probably. If it is too much work to debug this just drop it. It seems to be a very special case of configuration, server variant.

Patch attached which addresses this - filter and object selection done on a new getToOrCCAddresses call. This patch is based off stable branch commit 58375fa9e6db4a389fd6029ee1ad14ddb0dc9e90.

Using postfix instead of sendmail

Sorry for the typos :D, Step by Step Guide:
Follow this: https://secure.phabricator.com/book/phabricator/article/configuring_inbound_email/#local-mta-installing-mai (Local MTA Section)

We could possibly remove it entirely since I think it isn't useful for 99% of users, but D17144 just fixes the command.

Funny, never knew we put that text in that drop down.

Sorry, Step By Step Guide:

That one is somewhat interesting because the user created a safe-looking object, then edited the objectionable content into it. I had hoped we might see a few years of uneasy peace before things escalated so far.

Please read Contributing Bug Reports carefully, specifically we require a complete, easy to follow and under.stand, set of steps to reproduce the problem.

Please read Contributing Bug Reports carefully, specifically we require a complete, easy to follow and under.stand, set of steps to reproduce the problem. I also don't understand what you're saying the bug in Phabricator is.

So, just some insight, I use postfix as mail server and for catch all mail (@domain) I used the canonical approach. This results the error above. Using virtual as described here will solve this problem.

@PicoCreator:

1. Paste the patch into a $FILE
2. cd $PHABRICATOR_SRC
3. patch -p1 < $FILE

Endless war continues with E1323 😉

On my laptop it triggers either to the right of the preview icon or to the bottom, on my desktop, it does top, and gets jittery.

I think this really is the same as T10687, but the jittery bad degenerate behavior is only when a scrollbar gets added, so probably laptop + mouse works to repro but not laptop + touchpad?

Thanks for the excellent bug report with high-quality reproduction steps. Your clear, thorough reproduction steps made fixing this issue extremely easy!

Cry in vain this step is optional.

Specifically, this was already improved by D15726 in April 2016.