I second this, I sign all my commits too, and only just now discovered (because of this task) that things I have landed are signed by me.

This feature is very important to me, so I've been following along. However perhaps I'm missing something and cannot get the new functionality to work as I expect.

In T10349#177108, @joshuaspence wrote:

I thought that there was already a ticket for this somewhere, but maybe not?)

Sure, let me split the subproject/workboard piece out and we can walk through it. (I may not get to this tonight because I have had a long day of Business Things.)

Would it be possible to prioritize part of this ticket? Specifically, the use case mentioned in T10627? We are also interested in the ability for members of a project being able to create subprojects without requiring global "Can Create" permissions for Projects (I thought that there was already a ticket for this somewhere, but maybe not?)

On the "public preview" use case I do think "--plan-changes + [DRAFT] in title + just let Herald triggers fire, if users configured them they can deal with knowing about your not-quite-perfect-yet changes" is fairly reasonable, which is part of why I've resisted pursuing this until now.

(not that adding the feature would harm us, just my 2 cents)

We have a particularly opinionated set of developers here (when I say "opinionated", I mean roughly, nobody ever agrees on anything) and we've managed to successfully argue in favor of just using "plan changes" rather than opting for some other intermediary or distinct state. It correctly communicates to reviewers what you should want them to know: you're not done with the revision yet. Far and away the largest reason why this is our accepted workflow, rather than pushing on upstream to implement a "Not Yet Ready for Review" state is very tightly coupled to the entire concept of why Phabricator does review the way it does:

to avoid accidentally forgetting to pass an additional option in cases where you did intend it

Another possibility is:

We've never seen any real interest from other installs in a default preview-before-publish mode, and I'm not aware of any class of mistakes that users routinely make or wish to correct which this mode would aid in (if I was, we'd try to detect/fix them in arc diff so users didn't need to go to the browser). We've also never seen other interest in the annotate-before-publish use case. T949 is the only task in this vein that I was able to dig up, and focused on previewing the diff only. I'm not really sure what problems this mode solves outside easing adoption when coming from another tool which works like this.

For localization, I'd expect to customize timezone and Time format (24/12 hours), and maybe "Week Starts On".

In the "final look before publishing" use case, the best value for "Reviewers" is probably the final, effective set of reviewers (i.e., including reviewers from Herald and Owners), so you can see exactly who the revision will be published to. In the competing "share with a few people" use case, the best value for "Reviewers" is only explicit reviewers (you don't want to notify or involve others).

+1 to what Eitan said. The first two of those for sure. The first means we have this horrendous patch in place today in order to make it happen so we don't flood everyone with email :)

We want to be able to set

• email settings. We handle specific types of email OOB of phabricator. For example "X is committed" and "X reverted Y" (audit-commit and audit-other mailtags).
• default time zone. Most, but not all of our engineers are in P[DS]T instead of UTC. We'd like to set this as a default without making it a server-wide mandated value
• Default "Pinned Applications".

Current "Homepage" in general is not long for this world. We'll get rid of current hardcoded homepage, and build stuff from Dashboards / PanelNavs I imagine.

Being able to change the default set of applications shown on the side panel would be really useful for us. Not sure if this was split off though.

As a sanity check here before I actually build it, is anyone who is interested in configuring global default settings interested in configuring any settings other than mail-related settings? Or is this just T9161 in an alternate form, practically speaking?

Naturally people can work on what they want – that is the promise of open source. I am not contesting that. What I do want to make sure is that our values and goals are aligned. For example you and we recommend people to collaborate first. If we are sufficiently aligned, I don't see much need to continue discussing about things that might or might not happen.

I see. Thanks chad.

Competing translations are waste of resources and choice is not good for users.

If we submit patches, say once or twice a week, will you be able to review and merge them before the become stale?

Usually, yes, but I can't promise we'll always be able to review patches promptly.

We managed to solve this on our server setup using Linux ACL (I had help from someone in IT). Here are roughly the steps we took

I do not know what are you main concerns [with direct commit access].

Confirmed workaround: set base project edit permissions to something other than Project Members.

@sascha-egerer that would seem to be the main factor, and the reason this couldn't be duplicated initially. It isn't all milestones - it is specifically milestones for projects that have subprojects.

Like you say, Phabricator is a big project. This means I am willing to give some amount of special treatment to it that I would not give to smaller projects because that would not scale. For example, requiring all messages to have message documentation up-front is unreasonable. But a good way forward would be to establish good practices such as:

• having message documentation for new or changed messages;
• accepting bug reports and patches about source texts;
• and enhancing and enforcing best practices in code review with regards to parameters, plural handling etc.

My primary concern here is that I strongly dislike adding options to the product

I'm not sure how to describe it differently.

OK. I'm not sure how to describe it differently. However if being able to display milestone end dates on the calendar or organise them by date is out of scope of phabricator, please close this task.

Commit objects are not GC'ed in Phabricator?

Deleting the branch first won't have any effect, since the commit still exists.

Deleting the branch first won't have any effect, since the commit still exists.

My general line of thinking is that providing a better idea of a "context" to arc unit (e.g., diff vs build) and letting it make a default decision about which tests to run (possibly including no tests) is probably the most promising way forward here. You could still override this context with some kind of arc diff --run-some-extra-tests flag. I'm not sure if hard-coding a small number of contexts or making them fully user-configurable or something in between is the best way forward. This is probably a longer-term thing.

Sounds like a dup indeed. What's the work around?

• Doing a rebase instead of FF-merge?
• Deleting the topic branch in Diffusion first, then FF-merge and push?

Developers do run the test suite locally if they suspect they probably broke things though, it's not "never", it's just "infrequently".

Yes we use arc unit as the chokepoint for "consistently run unit tests as far as phabricator is concerned", and use the --target flag when harbormaster is running the tests.

Please see Contributing Feature Requests, specifically this task does not describe a problem or root issue using Phabricator.

We have a somewhat-legitimate technical reason for this behavior: when we compute which-packages-own(list-of-paths), we do so by splitting the paths into components and then querying for the components. a/b/ is the best database representation for this.

This was a legitimate upstream bug and I was able to reproduce it by following your steps, thanks for the report. D15971 should resolve it.

If developers generally don't run tests locally, is having arc unit do anything really valuable in your environment? That is, if you solved this by de-configuring arc so that arc unit did nothing, what would you lose?

Is this the same as T6522? I'm not sure where the last screenshot came from, I wouldn't expect an FF-merge + push to trigger another evaluation of Herald rules.

Great, glad things are working. Let us know if you run into anything else.

Looks like that value was removed when the update happened as it was there before (checked with a backup).

This appears to be stable and working properly, at least for the most part.

Should be as I've only used SSH for the hosted repos - I will double check now.

Does your configuration satisfy the conditions described in the documentation?

This service has no relationship to Apple Computer Wiki, and can not help resolve your problem.

I think nowadays the biggest issue (as it is the most work to manually correct afterwards) is two folks editing a task description at the same time and silently overwriting.

three times

tes 22

In T5267#176885, @epriestley wrote:

• We get a "sync" process working, so strings can be imported from Phabricator to Translatewiki.
• We get an "export" process working, so strings can be exported from Translatewiki to a format we can read.

For us it would be very helpful to support Windows agents.
We mainly use the phabricator for devops tasks in a microsoft environment. So we develop several powershell frameworks we need to test before deploying them.

@CodeMouse92 yes the project has a subproject. But changing the policies as described above works around that issue.

I just looked the description in 74e117ae41dd.

In T11012#176923, @chad wrote:

We require reproduction steps on all bug reports, this way we know we're fixing your actual bug, and have a means to test and verify any fix. As Owners was recently overhauled with many new features, it's hard to identify what case we may have missed in testing.

I understand that. Will try to find reproduce steps.

I have not found a concrete way to reproduce it. Sometimes the status is correct and sometimes it's not and I can not find any difference on those commits yet.

In T11012#176731, @chad wrote:

This may also be T11015.

In T11012#176668, @chad wrote:

Please follow all the steps in Contributing Bug Reports. Specifically we need to know how to reproduce the issue locally.

This is because that credential is in a restricted Space so this is ultimately the same as T9771, I'm just going to merge it there. The actual Query looks to be implemented fine so I think this is purely a Space issue.

I know this was linked against my question, but I wanted to check and see if it is the same thing...

Thanks!

I think the largest source of concern here is the (1b) and (3) rules: we aren't willing to exclude translations from other sources, and we aren't willing to give anyone direct commit access to the upstream. But Phabricator supports loading translations from external libraries, so we don't actually need to resolve these issues.

This seemed to fix the issue:

From the server logs:

Phabricator version is rPe1ad312fdd2c570eeaacd3e02eda2142cc5d9849.