Closing this as it's not a bug. General feedback is fine on T10349
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 28 2016
In T10163#154382, @epriestley wrote:
- D15039: Two effects:
- If you finish typing a word (e.g., type a space) and there are no results, deactivate since nothing else you could type could possibly cause matches and you're probably not fishing around since you just hit space.
@epriestley Maybe one to consider: you must have a default workboard column for a project; the default workboard column cannot be hidden; milestone workboard columns strictly sort after project workboard columns. The combination of these three means that I have a project which is strictly split into four milestones, but its overall workboard view always includes an empty column before each milestone column. Is it worth filing a task for this?
Thanks. I'll upgrade then.
This should be fixed in Week 17. See T8952 / D15773. Let us know if you're still seeing issues after upgrading, or can reproduce the problem on this install.
In T9161#136555, @epriestley wrote:My personal, completely subjective experience is that Phabricator mail is trivial to deal with, almost all valuable, takes very little of my time, and I want to receive >95% of the mail that I receive, and that I'd barely notice if I had 10x this mail volume.
I'm not looking for support for third-party packages. What I am trying to offer is a contribution to your 'as simple as possible' instructions.
Apr 27 2016
we'll get to it when we feel like it (ok not a totally fair paraphrase, but it's one way to read it)
Unfortunately we have 1,500~ish tasks between 2 developers and we do our best to build things that we think we have the largest impact (which tends to mean small quality of life stuff doesn't happen as often). We'd love to bring more people on board to help improve Phabricator faster, but that means being evil and chasing money first to make that happen.
I guess I was hoping for a timeline. Or an explanation of why it's hard
and not done yet. That page seems to me to say "we'll get to it when we
feel like it" (ok not a totally fair paraphrase, but it's one way to read
it). Waiting a year for a minor feature that would drastically improve one
of my workflows just makes it feel like you guys aren't being very
responsive to feedback about how the UI could be made better. And I have
plenty of other complaints about the ui - just haven't bothered filing most
of them.
Perhaps helpful for context is T6027, which was open for longer than this (about 18 months).
What isn't helpful about it? I believe it has a complete answer to your question, and a great deal of detail explaining why that's the answer. How could it be more helpful? Did I misunderstand what you're asking?
that was not a particularly helpful response
I suspect this isn't a bug -- diffs have repository associations, and you must be able to see a repository to see associated diffs. You must be able to see the active diff to see a revision. So andy caused the active diff to belong to a repository that nuno can not see, which prevents nuno from seeing the revision.
I'm going to merge this into T10748, which is now more clearly the way forward.
See Planning for information on timelines and progress.
Any updates here? This task has been open for over a year now and it's something I wish for approximately weekly.
Would it be possible to add something similar to Apache's SSLPassPhraseDialog exec:/path/to/program directive?
I'm going to merge this into T10748, since that's now clearly the way forward.
I'm going to merge this into T10748 because that's clearly the pathway forward now. You can view the new UI at /diffusion/X/manage/, although it mostly doesn't work yet and there are no links to it in the UI.
T10751 and T4292 are reaching a steadier state now and have some indirect/soft dependencies on this (for example, the new panel for monitoring the cluster status of a particular repository is part of this new UI) so I expect to drive this forward at least somewhat in the next few days. I'm not sure how ambitious I'll feel about meddling with the URI code before the release cut, but there's a good chunk of basic work remaining before that becomes an issue.
See also Contributing Bug Reports:
The instructions are correct as written, and are aimed at being as simple as possible for users who may not be familiar with PHP. We can not possibly include instructions for every imaginable installer, see also T4200.
I didn't use the windows-binary installer, I installed php into my cygwin install using the cygwin installer. (It's still on windows, but through another process).
In particular, the install instructions tell you to:
How did you install PHP, exactly?
Yeah, measuring latency and using it as a signal is tricky. If there's a long disruption and Oregon measures faster than N. California for "a while", we probably legitimately want to use it. If N. California completely goes down, we almost certainly want to keep things alive and send writes to Mars, even if Mars is at a huge network distance, since "slow write" is probably almost always better than "complete failure" (although maybe Mars bandwith is so much more expensive that we don't want to fail over to it, or the size of the link is small enough that it simply can't accommodate the failover traffic).
https://phabricator.wikimedia.org/T129049#2242513 was quite easy to do using iceweasel on debian on android 10" tablet. It involved moving the task from Backlog to the last column which wasnt visible on the screen. This might be more difficult with larger workboards, but there are definitively scenarios where this is painless on a tablet, and is a natural UI for the action on that type of device.
I wonder if it is any more difficult on high res smart phones in landscape mode- I suspect it might work quite well also.
I mean none of these things are show-stoppers in the example above, but you can imagine how bad things would be over a link between the Sydney data centre and N. California if it was happening all the time.
There's probably almost certainly a correlation there that link speed increases with lower latency because of proximity? But having an SSH proxy accidentally pick a link that's say in Oregon instead of North California because at the time of sampling some local network issues were being had that made the local copy appear worse would be a reasonably bad situation for a few reasons:
Ah, link speed vs latency is interesting.
Is "use measured latency" probably always the correct rule in your (hypothetical) cluster setup? Or do you have any cases offhand where it isn't the desired result, and you really want to send traffic to a more distant node on the network?
Gut feeling is that network latency almost certainly isn't the only reasonable concern here.
I don't currently expect anyone to be deploying multi-region clusters in the first iteration of real clustering
I don't currently expect anyone to be deploying multi-region clusters in the first iteration of real clustering, so this isn't high on my list of things to fix in this round.
See also T10884 for related work: ranking similar nodes more intelligently.
See also T10883 for related work: making some nodes read-only.
http://phacility.com can still up a clean test instance in under a minute.
Should note that with the test video I posted, I was able to replicate with a brand new workboard with 5 extra columns (6 total) with zero tasks on them, so the vertical scroll bar has no impact on it.
Apr 26 2016
Tested with:
arcanist: rARCa2ab38df78a9d111459fab8d0d63e74d811edf29
libphutil: rPHU4b44d03ba60c8a67f70a91cb11765b8b61f73598
What version arcanist are you running?
Knowing what the problem is, the workaround is obvious (remove the relevant git config option).
I am involved in few projects and I have several issues for each project.
Thanks -- T10778 had instructions which I was more successful with. This should be fixed in HEAD.
@epriestley I updated the description in this ticket.
Oh, thanks. I can reproduce this variant of things. I thought I remembered seeing this...
Do you have a stack trace in your webserver error log? (Often /var/log/apache2/error.log or similar.) I can't immediately reproduce this myself, but that might help narrow down the cause.