Contributing configuration changes and downstream patches: Our custom settings are available in operations/puppet under /modules/phabricator/data/fixed_settings.yaml

Instances: If phab-01.wmflabs is supposed to simply reflect the current production setup (translates to no playing around on whatever UI or shell level), there's need for another staging instance (testing changes pulled from upstream before deploying on production). Like "Production is on revision 123, testing revision 156 on staging" with a related ticket "Upgrade production instance to rev156" under https://phabricator.wikimedia.org/tag/phabricator/ or such (no idea why https://phabricator.wikimedia.org/tag/phabricator.wikimedia.org/ exists in parallel. And we have https://phabricator.wikimedia.org/tag/wikimedia_phabricator_maintenance/ too!). Same project where people can propose their enhancement ideas that we might never fix.

In T461#5, @Aklapper wrote:

Contributing configuration changes and downstream patches: Our custom settings are available in operations/puppet under /modules/phabricator/data/fixed_settings.yaml

If we want to change the policies of, say, Legalpad, can we do it via the web interface or does this need to be made through Gerrit changes.

Same question at a project level. If we change the policy of an existing project, or we create a new project and change the default policies, can we do this via the web interface or must be done via Gerrit changes?

Instances: If phab-01.wmflabs is supposed to simply reflect the current production setup (translates to no playing around on whatever UI or shell level), there's need for another staging instance (testing changes pulled from upstream before deploying on production).

Well, I had requested a Phabricator instance in Labs where people could play around at will, including trying out applications not available in production. It is ok to sync back to production i.e. when the latter is updated with upstream or something, but its main purpose is to be a playground (at list this is how I understand it, and we can discuss, although maybe after Day 1).

under https://phabricator.wikimedia.org/tag/phabricator/

yes

(no idea why https://phabricator.wikimedia.org/tag/phabricator.wikimedia.org/ exists in parallel. And we have https://phabricator.wikimedia.org/tag/wikimedia_phabricator_maintenance/ too!).

These two projects have been archived.

Only commenting on the aspect "admin UI settings vs. settings in a Puppet file": We have /modules/phabricator in Git in the operations/puppet repo, especially modules/phabricator/data/fixed_settings.yaml but I myself am also a bit lost what to do where or not, see e.g. Chase's comment in https://gerrit.wikimedia.org/r/#/c/161624/ that settings in that file "should only be things we want disabled on all installs and by default" while actual management of a specific instance should be done through the instance's admin UI interface.

I have started drafting https://www.mediawiki.org/wiki/Phabricator/Code

Edits and feedback are welcome.

I hope the explanation of what kind of patches to submit where, and when to use the web admin UI instead, makes sense to you:

https://www.mediawiki.org/wiki/Phabricator/Code

Edits always welcome.

What is still missing is the "Setting your development environment" part. I want to eat own dog food and document while setting up Phabricator in my laptop and in a Labs instance, but I need some help.

Let's start with the local install. Are you doing this, cloning the version upstream or our phabricator/phabricator? Should I follow the official installation guide (for Ubuntu in my case) or is there a better procedure for wikimedians?

Also, is there a clear answer for when you are fine with a local install and when you need to create (also?) a Labs instance?

If you want a close to wikimedia experience then labs is going to be easiest, and linking to the existing labs docs w/ the note that you apply the phabricator::labs role is the right thing.

The isn't a right or wrong thing, but if someone is doing local only and using upstream repo's I would say us supporting their efforts is mostly futile. If they are using labs w/ our setup then it's much more normative, and useful for all involved. But you could use our labs role on a vm, I just don't know about it. All the labs stuff is well documented, no real need for special notes I think.

Thank you for the clarification. I will keep editing this page, but I think in its current state is already good enough to give the basic hints to anybody really interested. Moving it away from pre-launch.

that looks pretty good to me actually thanks. The only thing I might add, and I'm not sure where, is a bit of emphasis on the idea that _extensions_ are able to be included locally without incurring the cost of merge conflicts / constant management overheard from local patching. Any custom phab stuff is going to be have a much, much better chance of getting included outside of upstream if it is done that way, and anything not done that way will have to be approved by OPS because of the increased overhead for testing and merging. I would say I am opposed to all local patching I have seen to this point not security related.

Dunno if being more explicit there is good, but maybe saves someone a false start.

thanks

Very good point. Added> https://www.mediawiki.org/wiki/Phabricator/Code#Phabricator_extensions