I've contacted Atlassian about this. They told me Sourcetree tracks branches automatically to cope with git's push.default setting. By default this is set to 'simple', which means git will push the current branch to a tracked remote branch that has the same name as the local branch.

No worries! Z1336: General Chat is a great place to join and chat with the community if you're inclined.

Its just suggestion as i say, mabye you deems it useful for yourself. Sorry if i written about it in wrong place, just wanted to give you a useful application for improving the convenience in your work)

If your developers are already doing this today, what's the feature request? See Contributing Feature Requests for what we look for in requests. Mostly, it sounds like your company has a local process already for this. I haven't heard of any other install with a similar process, so I don't think in general it something that should be brought upstream.

I deployed this stuff, and I'm actually seeing more used ports now on secure001 than I did in D16389. However, I think most of these are coming from web requests and the larger count is because we have more traffic during US daytime than we did earlier in the morning. It didn't occur to me earlier that I'd be accidentally counting connections from both sources.

No problem, thanks for the report!

I just did a Ctrl+Refresh and it looks correct. Sorry for the dupe (I searched "gradient" but didn't find that revision).

I think this was resolved by D16381, I just didn't deploy it until a moment ago.

My expectation is that reviewers do not accept code which isn't ready to go upstream

Yes this expectation does hold for us as well, however comments often do continue after acceptance, which results in a question of why was something accepted if there was more to say. Having a way to distinguish that an inline comment was specifically asking for a change or not (or some other type/context indicator) would simplify these explanations. This is not a huge issue for us, I was more trying to give a perspective of non-developer being a consumer of code reviews.

In T11450#189882, @epriestley wrote:

How did the author/reviewer know it was ready to go upstream in this situation?

My expectation is that reviewers do not accept code which isn't ready to go upstream (maybe it could be improved, but all remaining feedback is essentially optional), so the author and reviewer knew it was ready to go upstream because the reviewer selected "Accept".

Is this not the meaning of "Accept" in your environment? If not, what does "Accept" mean to you? When do reviewers "Accept" code which is not suitable to publish in its current form?

How did the author/reviewer know it was ready to go upstream in this situation?

Check this out if you haven't seen it yet?

@epriestley - I currently don't have the permissions to edit feed.http-hooks -- it claims I don't have permissions to manage the "finxpc.phacility.com" instance, however I'm apparently an admin on it. We (Danny, the person who set up the instance and I) have also been unable to figure out how to grant me any different permissions - could you please give us a nudge in the right direction? Danny also appears to be an admin, same as me, but has permissions to edit that variable.

Generally the reason we ask for feature requests to state problems, and not solutions, is that we have a backlog of several years of requests. The request would likely be entering a long tail and may never be built in a reasonable timeframe for your use. By stating the request as a problem, we may be able to help find a solution, though imperfect, that works for you today or group your problem with other similar problems that might lead to a more streamlined solution. We'd rather find a way to help you today than let a request sit in Maniphest for years before it gets addressed.

I don't understand what this ticket is about then.

I used the Responsible Users field, as I'd like to see reviews that I have created, not only those for which I'm a reviewer. Bucket by Action is really nice, and filtering by Reviewer limits its usefulness (indeed, No bucketing is automatically forced).

This seems to be what you're looking for specifically?

Unfortunately this means that the "My Reviews" panel becomes unusable for people in the #reviewers group, listing nearly every revision under the Sun.

We don't currently plan to bring any more third-party linters upstream. Instead, we're going to make it easier for users to write and distribute linter bindings themselves.

In fact, this also happens with other panels. Basically the top right panel will always be duplicated to bottom left.

I have the similar problem.. Sometimes web UI shows setup issue warning "Phabricator Daemons Are Not Running". Then I restart daemons. They work fine for some period (may be a week or two). And then again "Phabricator Daemons Are Not Running" is showed...

To add another perspective, several of the above use cases also apply where non-developers are looking at code reviews as quality documents, in an audit or quality department review. Being able to easily differentiate between Change Required and Discussion\Question types of comments would make these situations easier to explain/answer -- ex:

• Explain this code review from 8 months ago where comments were made but no followup code changes were done. How did the author/reviewer know it was ready to go upstream in this situation?

Being able to show that all Change Required comments were addressed while Discussion\Question may not have been is something they can consume and move on.

i can confirm

Thanks @epriestley!

Thank you for exhaustive description. One more question:

Thanks for the attention and detailed thoughts. I really appreciate it. I
agree with your comments re standardizing the test interface. This
resolution makes sense to me.

In T8145#113258, @epriestley wrote:

Does anyone have a use case for this which isn't maintenance notifications?

You could also do this with no custom code by using Herald to trigger a Harbormaster build and having that make an HTTP request to something which runs the logic, or theoretically by using feed.http-hooks or Doorkeeper (although these are probably better after T10363).

This reproduces for me as described.

I haven't seen more segfaults since I switched.

Presuming this is resolved since we haven't received any more information in about a week.

• We'll provide a third generation differential.diff.search endpoint eventually which will be able to do this lookup in a modern, consistent way, but have no particular timeline on this.
• I'm open to accepting a patch to add 'phid' to differential.querydiffs in the meantime.
• I don't want to bring "Diff X" upstream as an object name. This (English word + space) is inconsistent with other object names, ambiguous in some contexts like CLI revision messages, surprising in other contexts like fulltext search from the global menu, and faces more internationalization issues than existing monograms.
• You can create repositories via third-generation API methods, see Diffusion User Guide: Repositories API for guidance.
• See T9766 for Herald control via API, although neither that use case nor this use case are very strong from my perspective.
• Harbormaster will get more API support eventually, but see below.

In the general (Phabricator, rather than Phacility) case we could also suppress that warning while "NUX Mode" is active, for whatever "NUX Mode" means. Presumably, it's not important to fix until you get through whatever NUX flow we end up with. This would indirectly reduce the annoyance for Phacility instances, although sync is still better.

@jmeador, this error should no longer be misleading in HEAD of master. Let us know if you run into more stuff, and thanks for the report!

I'll file something just to keep separate.

@scode, @lvital, having this level of detail on your issues before attempting T8250 is immensely helpful.

We definitely should sync it, and probably at least some other stuff, like language and pronoun, which may not be relevant now but is likely to be relevant in the future.

+1, let's revisit after T11451/T8250 and us shipping that to our users.

I'd be more comfortable just saving the description if we didn't have CustomFields. I think we do something similar in Phriction today.

So first thing I notice when starting a new test instance... Phabricator wants to set my Timezone, so OK fine, click save, get redirected to settings. Is there any means of pre-populating that before the user first logs in from admin maybe?

See also T7216, which I plan to solve primarily via T5307. This isn't too closely related, but is a somewhat-similar Dashboard configuration usability issue.

Yeah, I think we're definitely going to build T8250 before anything here or on T11451.

This discussion also doesn't really seem to define an upper bound on this feature, at least to me. If some explicit classification ("issue" vs "non-issue") is good, why isn't more better? Almost all of the arguments for this classification seem to support adding many different options ("compliment", "suggestion", "fyi", "issue", "really important issue"), perhaps multiple dimensions of classification ("serious comment", "joke intended for humans"), etc.

At least, I assume we all want to see T8250 first?

I do understand the desire to be able to more accurately frame the feedback, but I'm probably not onboard with introducing a new workflow that we need to maintain, support, and educate to all Phabricator users. I still think no real discussion can come of this until we revamp the inline / done UI. If we have a new inline/done UI, the ability for reviewers to pre-mark dones and have an option or warning when things land before they are marked done, I think from a high level that achieves the same overall goal?

wow sorry :(

In T11450#189548, @epriestley wrote:

1. The author initiates a remedy and immediately comments on the revision, like "sorry, I got interrupted and missed some of this, I'll fix it up", then promptly sends you a followup change to address the feedback.
2. The author doesn't initiate a remedy, but is apologetic and prompt in fixing things when gently prodded ("Did you miss this?") or apologetic and prompt when sent a followup revision.
3. The author doesn't initiate a remedy and is anything less than than apologetic and prompt when gently prodded (e.g., ignores a followup).

I don't think I've ever seen (3) in a professional setting. If anyone is seeing (3), this is probably not a behavior with a technical solution.

My expectation is that intent is conveyed with the plain text of the comment without requiring any real effort on the part of the reviewer, and that the use of human language allows reviewers to express a very wide range of types of feedback.

It's not optional. It's important to not confuse the fact that pressing the button is optional with the fact that a new decision has to be made with every comment.

It's not optional. It's important to not confuse the fact that pressing the button is optional with the fact that a new decision has to be made with every comment.

A few thoughts.

D16385 increases the storage length of the underlying column. Summaries will now be cut to 255 bytes or 80 display glyphs, whichever is shorter.

See D16384.

I think this is resolved as best it can be today, let me know if you still have questions.

Put another way, we're routinely asked to work around bugs in other software by applying patches to Phabricator, mostly because we're usually pretty responsive and have a short release cycle. For example, T11362 asks us to work around an unusual behavior in some GUI VCS tool, rather than asking that tool to adjust the behavior. Sometimes putting a workaround in Phabricator is reasonable, but I think that in most cases the onus should be on that other software to work correctly. If we took this to an extreme, we'd end up shouldering a huge complexity burden for bugs in other software.

(For now, I'm inclined to let this and T11450 run their courses and then talk about how we can improve meta-issues afterward. I think both of these tasks will serve as good examples of our concerns.)

In T11449#189499, @em wrote:

Is it ok for me to retitle this feature request?