@chad - How can I be involved with any progress on this front then since now it is planned?

I wasn't trying to create a whole new discussion. I respect your priorities and I also understand the engineers vs. money problem. The only major problem I see with the contribution guidelines is this: to be able to contribute more or affect change, you need clout and to get clout you need to contribute and for those contributions to go into the code or even get some feedback we need time from you guys.

@chad - You know how can you get more developers? Being more open to contributions :)

@eadler - oops, sorry about that then :) I'm still behind what I said though ;)

@eadler - I'd like to remind you that there are 3 patches waiting for review right now. They have been sitting there for a few months. That said we are not paying Phabricator. If the only way to get these patches which are already worked on and in pretty good shape merged in is to pay you or maintain a fork I'm really starting to think about crowdsourcing this on Kickstarter or Indiegogo to collect those few hundred bucks to get already working patches landed or simply create a fork and point people there loudly. I also think I almost qualify for "Rise to prominence" sub-section mentioned in https://secure.phabricator.com/book/phabcontrib/article/contributing_code/#alternatives but of course that also relies on you guys letting me contribute more. Making patches sit for months without any feedback and then making me rebase them multiple times is definitely not a great way to encourage people to "Rise to prominence" if you really value that.

This is another reason for me to dislike PHP but I really appreciate the time you've taken to explain the issue in addition to a promising fix for this task. Couldn't have asked for a better new year's gift :)

If so, I'd generally claim this is an issue with the client you're using: I think clients generally should not do parameter validation themselves. They will always be less able to do validation than the server is, even though server validation is not especially sophisticated right now. If/when we have a formal Python API client, it is very unlikely to perform client validation. Does client validation provide any advantage?

I'm fairly certain since it seems to be using the CreateProcess API as others do. I'm also using xonsh (the project using that Python code) for quite some time now and it works without any issues.

@epriestley - okay, may be the name mislead me. Anyways, I'm basically proposing making bypass_shell on by default in execx and implementing a mechanism that automatically finds the full path of the executable on Windows by implementing that Python function I referred to. Does this make sense?

How does that obsolete PhutilExecPassthru?

Okay, proposal: how about we implement the equivalent of this: https://github.com/scopatz/xonsh/blob/fa356d728b2852274f8aa0260dc7da3b7b0f08ab/xonsh/built_ins.py#L268

Oh god, and I thought Python's subprocess module was pretty bad.

bypass_shell (windows only): bypass cmd.exe shell when set to TRUE
5.2.1 Added the bypass_shell option to the other_options parameter.

Seems like this happens when you have multiple layers of dependent diffs.

Since many engines support common output formats (I think?) like XUnit (I think?) separating parsing might be valuable here, while it's not very useful for lint.

It looks like this is probably not a bug then, and D12211 is a fairly reasonable fix.

I think this is the reason: http://stackoverflow.com/a/9014547/90297

@epriestley - I was able to narrow it down to this:

This looks like a bug in Firefox to me, but I imagine reducing it to a test case is quite involved.

We don't provide support alpha/beta browsers. All bug reports should be against stable browsers and HEAD.

Windows 8.1 EN with Firefox Aurora 38. That said I've had this issue for the last 2-3 versions so it should happen on latest stable Firefox too. I can verify if you want.

Here: https://secure.phabricator.com/D12210#1753cdf4

This has been driving me and one of my colleagues crazy for a while now and he came with the following Stylish rule to get rid of it:

For our case, we use both arc lint and arc unit. We have a somewhat "smart" unit test engine that tries to run only affected tests up to a degree so test times are not a huge concern to us. Also the team I work with is ~10 people so there's no way we can go as high as 30 commits/hour, at least in the near future. We have a smooth CI system that is running tests both for each diff revision and every commit on master.

The UI shows skipped. Instead, it should just be omitted or show tailored messages that this is an update from the VCS. This is easy and just a display issue.