Welcome to the wonderful, spooky world of Quicksand.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 10 2016
We still do a pretty questionable job on the first case in T7643#180264, where a comma is removed from the middle of a sentence.
Do you have the persistent chat pane open?
Would you fill out at least, like, 5 of them?
Yeah, I think it's pretty reasonable if people would actually fill it out. We could surface it in a few other places too (e.g., /projects/) without fallback. It just seems like there's a decent chance no one will ever fill it out and it will sort of just be cluttering up the UI. But the cost on our side is pretty small, so if some people claim that they'd probably want to fill it out I'm happy to move forward with it.
For reference, here's the current state of "discovery" downstream:
I'm going to kick this out of the queue for now and we'll reconsider it alongside other internal priorities once the queue clears. I think it's probably secondary to Conpherence now, at least, product-roadmap-wise, maybe?
I'm going to kick this out of the queue for now and we can re-evaluate our internal priorities once the queue clears -- we got a decent iteration out and it looks like the next steps on NUX are probably a fair chunk of work.
The driving install dropped off the grid a while ago, so this is no longer prioritized.
I believe this is now resolved, in the sense that I expect all specific, reproducible examples I'm aware of function in a way consistent with user expectation. In particular:
I have some possible approaches for cheating on the "more than 100 results" case, but I think we ultimately need to put the prefix paging rule on the server side, so we return all prefix matches and then all content matches. That's kind of a big mess, but all the ways we can cheat will break down at some point (e.g., when you have 100 "wikidata" projects that are alphabetically earlier than "wikidata") so I think it's not avoidable.
- Prototype applications must be enabled.
- security.outbound-blacklist must not blacklist the target server (build servers may be on an internal network and on the default blacklist).
- The link protocol must be "http" or "https".
- You must not have exceeded your fetch quota for the last hour.
- You must have file storage configured.
- The image MIME type must be part of files.image-mime-types and files.viewable-mime-types.
- The Phabricator server must be able to make outbound requests on the network.
{img https://static-cdn.jtvnw.net/jtv_user_pictures/doritos-profile_image-4328d01909178d94-300x300.png}Pausing this from our perspective since we're waiting on guidance to move forward.
Presuming this is resolved since it hasn't been updated in about a month, but let us know if it's still an issue after the update.
D16837 should clean this up. Thanks for the thorough report!
Some discussion of current context in T10448#186240.
I'm going to merge this into T7580 since I think that's the same task?
I added "Mentions" (and "Mocks") recently in connection with T4788.
This is sort-of-maybe related to T11482 but I'm also not exactly sure what's step in the process is slow here.
I'm happy to change this if anyone comes up with good alternate wording, but I think this might be about the best we can do.
never mind I love the text area
Yeah, the upper-right action thing is a little weird since we don't use it in other applications, but it has felt OK to me once I kind of got used to it / continued being too lazy to change it.
Wouldn't miss it for the world!
This is probably the required test:
Nov 9 2016
Nov 8 2016
The policies work like you expect them to. This is just like a revision saying "All Users" but not being visible to users who can't see the corresponding repository.
It's just very
important to
thoroughly explore
the applications
(If we were better about figuring this out automatically -- which we may be soon -- would it be a problem at all?)
The distinction between "Earlier Revisions" and "Earlier Versions of This Revision" (e.g., earlier diffs) seems potentially confusing to me. That is, I could imagine a new user thinking "Earlier Revisions" meant "earlier versions of this change", not "prior changes which this change depends on".
Or, of course, we could do:
I think there was no web UI for this until T4788, which added both options. Prior to that, the only way to mark dependencies was by writing "Depends On" in text (which still works). So we didn't previously have anything else, unless I'm misremembering.
Our use of "parent" and "child" are consistent with Git's use of "parent" and "child", if that helps: for example, git help log discusses the ideas of "parent commits" and "child commits" in many places, and "parent revisions" and "child revisions" have the same relationship order as commits do in Git.
What specific, totally unambiguous labels would you prefer these actions to have?
Sounds good, thanks!
%s cannot be repeated as far as I know.
"aBmeIEk": { "one": "%s star", "other": "%s stars" },
Here are the current internal data formats:
Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.
Here's the XHProf link:
Nov 7 2016
This self-healed (probably after another commit was pushed) so I don't expect to look at it for a while unless it happens again.
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• Sorry, I've dropped my bag of Doritos™ brand perfect circles • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • •• • • •• • • • • • • •
The color should be fixed by D16819.
So far the pup is sleeping a lot and doing very little mischief.
At HEAD, I think the all-day issues with the French holidays above are fixed. You may need to reload the import for the change to take effect, but things seem OK for me locally now:
Ah, cool. I think that's a Zimbra issue, then.
@ivo, that's expected if you previously edited the Nov 8 instance. This is consistent with Calendar.app, although not with Google Calendar.
(mindrot.org is currently inaccessible for me so I wasn't able to read the details you linked, although I imagine they aren't too relevant to how we handle things.)
I was trying to import the french holidays from google ICS file...
The rTRANSLATEWIKI repository is now available. Here is an example of the en.json MediaWiki-style JSON string file we currently generate:
