Using command on Macs is fine.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 25 2015
Here's the general outline of how this should move forward:
Is this still an issue after D12574?
Where are the two-second delays occurring? Everything in that trace looks like it happens in no more than a few milliseconds.
Can you update libphutil and retry that? The duration printouts are bugged until rPHU65819efa.
Can you run bin/phd debug taskmaster for a minute or so and show me the output?
Basically, this is pretty much the same as D12965, except the processes are racing through PhabricatorFile::loadBuiltins().
I think this is a race condition on building "default" file resources.
Presuming this is a Bitnami issue.
These numbers are wildly out of line with expectations. For comparison, I just ran a similar workload on this machine:
I wouldn't plan for this to supersede the grey "disabled" dot or the red "away" dot in the general case (those show up in a lot of contexts where badges won't) but it would be reasonable to consider showing a special automatic "Disabled" or "Away" badge in timelines, like the proposed "Admin" badge.
Yeah, I'm OK with that. Thanks!
In the specific bad case in D12962 (applying a dependency that should not be applied), we can just check that the two revisions have the same repository.
I'm just going to pursue better queue monitoring for now; this is complicated and only mitigates a symptom.
I've converted vault to an m3.large instance. We no longer deploy any production micro instances.
Ah, thanks! That's helpful.
For the arrow, this is expected. Your first transaction has no primary comment, and the arrow does not let you take actions on inline comments (there may be several, so "Edit Comment", for example, isn't necessarily meaningful). This is a little confusing in the case of only one inline comment.
May 24 2015
You can pay us to prioritize this; see Paid Prioritization for details. I've previously quoted this as about 20 hours of work, and I think that's still accurate.
Can you provide some examples of what you want the rules to do? There are probably three general ways forward here:
You shouldn't, no. arc uses other information (mostly working copy path on disk, IIRC) in that case.
We haven't tried this before, and it seems reasonable to me to try. A couple of thoughts:
May 23 2015
I've converted the ELBs to use the ECDHE policy.
I may be misunderstanding, but here's what I think is happening from your description:
Disabled users, unapproved users, and users who have not verified their email addresses may be able to increase their effective permissions by logging out. In some cases, normal users can do this too (if policies have been written which deny them access to resources, but permit public users access).
Right -- can you disable Autoclose on the version-branch repository to work around this? Disabling it should stop commits to it that repository from associating with revisions, so the repository will never "steal" the revision (basically, Differential will just ignore the commit, even though it will still show up in Diffusion).
I might take a stab at this.
May 22 2015
"Block and wait" can deadlock the queue and we're going to have to stop doing that if we're doing it anywhere.
In T7447#112510, @jparise wrote:I feel like I'm doing something wrong. Perhaps "Done" should only appear once for each group of comments?
From T7447:
I think there's one more thing that only reproduced at your house too, although I don't remember what it was.
We don't have enough information to reproduce this issue.
Is this still happening? I've never experienced this myself.
That situation is unavoidable. Here's a way we can hit it with pre-checks:
I do think we can get the scrolling to work well, even if it feels pretty bad with the naive approach, but would have to do something like this:
The MIME type of these files is detected differently (text/plain vs text/x-php). We can probably force these to text/plain safely in all cases, but this has some security implications.
Particularly, this would be worse for me if we lost edit/delete-from-preview and only gained a slicker UI.
I'd maybe go the other way: there's no way to delete or edit inline comments from the preview in Pholio. I use these features fairly often in Differential.
We can't reproduce this on similar hardware/software, manage this stuff primarily with pure CSS (which makes it less likely that this is a bug we can fix), and it sounds like it's easy to avoid (don't do somersaults while using Phabricator), and to work around (reload the page). So we don't really have a path forward here, don't have a real reason to believe it's fixable, and the impact seems very small.
I want to add this kind of stuff as custom fields with options, after T6030. These aren't useful or desirable for all users, and if we add every option which someone wants we'll end up with email which isn't very useful to anyone.
Presuming this is resolved by D12967.
AWS has released a new LB policy (it looks like my understanding about the relationship between ciphersuites and DH groups above wasn't quite accurate):
- I think we already accept the primary hashtag, although maybe this is somewhat incidental.
- I think it's reasonable to accept secondary hashtags, although this may not be trivial.
- I don't plan to add support for IDs. We don't position IDs as a primary identifier for projects, and I don't think this is very useful for most users.
After thinking about this for a bit, I sort of question whether this is actually a very good solution. I think there are three root problems:
I think this was tricky because we don't know what kind of credential to add (the user could put either an HTTP or SSH URI into the box) and the "add credential" dialog workflow needs (or needed?) a type. There's no reason we can't ask the user for a credential type.
This is blocked by T8298: specifically, we don't currently know how to fix this in the general case.
In related tasks: