This task was filed through the "New Feature Request" form.
For (1), it's currently expected, yes. We don't create branches for dependencies in Git either, currently. I don't think this is terribly unreasonable, but I'm also not sure it's terribly useful (does it just help you keep track of which commits are part of the leaf?) and it makes cleanup more difficult by creating more total branch/bookmark artifacts in the local working copy.
For (1), it is expected to not apply bookmarks to dependency changesets that are applied as part of the patch issued? When patched one-by-one they would each obtain their bookmark.
Sorry, I should have led with a screenshot! I'm the biggest nitpicker, I know.
Some of the (3), (2), (1) stuff is that we're trying to pick a single behavior which addresses most use cases reasonably well. For example, if we use "natural" bookmark names that will tend to make things much worse for users in bucket (3).
Thanks, that's much more clear than the original description!
No they're not. I know it's a tiny difference, but look at this closely (left is my proposal, right is the current state):
I'm confused here -- the icons are already struck in every browser on my system (Safari, Firefox, Chrome):
Thu, Jun 22
Wed, Jun 21
Just to clarify, Phacility is the paid hosted version of Phabricator. If you installed Phabricator locally, we cannot help you with this request via Phacility. You'll need to follow Support Resources for your self-hosted installation.
Great! Please mail support at firstname.lastname@example.org and identify which instance you're paying us for, then we're happy to help you. We won't help you here, since this isn't the right way for customers to get support.
Yes,we are Phacility customer And I deployed it on a Ubuntu server,Thank you.
If you're a Phacility customer, please mail support at email@example.com (and identify your instance).
Mon, Jun 19
Sun, Jun 18
I was going to wait with updating this task until I'm finished but I'm stuck on GoCD side for some time. The extension for Phabricator is 99% ready so anyone interested may give it a try:
It's enough to be able to schedule a pipeline in GoCD but nothing more. This issue hampers my progress with notifying Harbormaster about pipeline status. I'll update this task when all is working as planned.
Fri, Jun 16
Milestones works great for this, but you still have to manually create the workboard (just going into workboard and clicking create - milestones show up).
Wed, Jun 14
I'm not totally sure about how/why users are expecting the behavior in the third case.
I'm not particularly strongly opposed to adding more options here, I just want to avoid the dropdown becoming this:
For the compliance case, you should already be able to trigger this stronger rule ("always add the package as a reviewer, even if an owner authored it") with Herald, by writing this rule:
As more of a point of philosophy of code review also, I (and, I think, my teammates) would say that diffs should be reviewed by someone who both:
- Understands the relevant code
- Did not write the code themselves
In other words, the combination of expertise + different perspective is of value beyond each component individually. If you believe that, then B or C should review A's diff in this case.
When you put it that way, it does seem backwards.
The use case in this task's description does not make sense to me.
We're interested in this option, since we find that users are often surprised by the existing behaviour. I think this would make sense as a per-package setting, rather than a global one.
It would be really nice to default newly added fields to hidden. Going through 20+ forms to hide the fields is tedious.
We do something similar ourselves for technical interviews, but I just related all the tasks by embedding them in the description of a central task:
I think this use case is a reasonable one.
Just discovered I could use the Milestones feature to do that. Will try this out.