Talk:Phabricator/Archive 1

Documenting our usage of Phabricator
In relation to the Phabricator RfC and http://fab.wmflabs.org, we are starting to see useful questions and answers about the way we use the Phabricator tools. Let's update this outdated page documenting here the good practices. The discussion about Wikimedia Phabricator yes/no still must go to Requests for comment/Phabricator‎.--Qgil (talk) 15:36, 24 April 2014 (UTC)

Test instance or not
«!NOTICE! This is a test install, be prepared to lose data or manually migrate to the future real instance at a later date. This instance is not meant for long term use.» but then it's said to be ok for posting important/production information. Who's right? Please update the notice if things changed. --Nemo 07:10, 9 August 2014 (UTC)
 * It can be used for "real" data by those willing to be guinea pigs, however everybody should be aware that some data still could get lost (though daily backups are in place, so in worst case you lose 24h). And it's correct that the specific Labs test instance is not meant for long term use - the production instance will be. --AKlapper (WMF) (talk) 11:46, 9 August 2014 (UTC)
 * I think the warning is fine to make sure that testers know that they are testers. However, "or manually migrate to the future real instance at a later date" could be removed because it is inaccurate. We are planning to migrate the valid projects to the production instance.--Qgil (talk) 21:46, 9 August 2014 (UTC)

fab.wmflabs.org down for migration
Summary: fab.wmflabs.org will be taken down this Monday 8th 18:00UTC. Locally save tasks or workboards that you might rely on for the week. Verify your email address in fab.wmflabs.org if it's not already. The intention is for the Phabricator production instance to be available by Sept 12th.

The Phabricator instance on fab.wmflabs.org has been used over the last few months for both real and test data. On Mon, Sept 8th 2014 18:00UTC this instance will be made unavailable to migrate content to the upcoming production instance on phabricator.wikimedia.org. The Labs instance will not come back online in the same form, if at all.

We take the Labs instance down because we cannot make the Labs instance read-only while dumping its data. Neither can we easily display a banner on all pages warning you to not make any changes which would get lost anyway.

Tickets from the following projects are marked for migration:


 * Analytics-EEVS
 * Architecture
 * bugzilla-migration
 * Chemical_Markup_for_Wikimedia_Commons
 * Code_review_in_Phabricator
 * Community-Engagement
 * dev.wikimedia.org
 * googlelogin
 * Growth
 * Human_Resources
 * Language_Engineering
 * logstash
 * phabricator
 * phabricator-request-project
 * Release_Engineering
 * rt-migration
 * Triagers
 * Trusted_User_Tool
 * UI_Standardization
 * UploadWizard_Refactoring
 * Upstreaming_to_Phabricator.org
 * Wiki-Release-Team
 * Wikimedia_Phabricator_Day_1
 * wikimedia_phabricator_maintenance
 * wikimedia_phabricator_rfc

Some metadata for tasks associated with the above should be populated in the new production system -- if the account used in fab.wmflabs.org has a verified email that is also verified in the production instance. If you are using an email but have not verified it to the Labs instance you can go here: http://fab.wmflabs.org/settings/panel/email/ and choose "verify". An email will be sent with a link.

If you do not have a verified email address yet, or for some reason cannot verify an email with the Labs instance the relevant content (tickets, comments) will still be migrated. However, it will not be associated automatically with any new account in the production instance.

For questions catch us (chasemp and andre__) on Freenode IRC or drop into the channel.

Thanks,

Phabricator Team

The FAQ
Just a heads up, I intend to keep the /FAQ, but actually bringing the answers to the wiki pages that should have them. You may expect to end up seeing a bunch of questions with links as replies. We are starting to accumulate duplication and dispersion, and we haven't even started properly with the on-wiki documentation.--Qgil-WMF (talk) 21:36, 16 September 2014 (UTC)

"Not done"?
"Automatic redirects from Bugzilla reports to Phabricator tasks" is marked as "Not done". Does this mean "won't fix", or it is just to say that work hasn't been started on this? I consider this, or something similar (e.g. a link from the header of each Bugzilla bug to the relevant Phabricator task) a blocker for the migration. This, that and the other (talk) 08:08, 20 September 2014 (UTC)
 * "Not done" means not set up yet. We also consider it important. --AKlapper (WMF) (talk) 09:29, 20 September 2014 (UTC)
 * Also, if you ckick the link, you will see that it is marked as "Ready to Go" in the Bugzilla-Migration dashboard. All tasks in this project are blockers for the Bugzilla migration.--Qgil-WMF (talk) 10:12, 21 September 2014 (UTC)

Why Wikitech accounts?
"you need to login with your wikitech.wikimedia.org account"

Can anyone tell me why creating a wikitech account is necessary for access to Phabricator? Is this always going to be required? Whatamidoing (WMF) (talk) 19:15, 24 September 2014 (UTC)


 * SUL login isn't ready yet. (which is one of the reasons registration is not open in general). You be able to link both SUL and LDAP (wikitech) accounts to phab accounts. And then you can login to phab accounts using any linked account. --Jeremyb-phone (talk) 19:42, 24 September 2014 (UTC)
 * Let me be slightly clearer: Why specifically Wikitech and not one of the many other projects where people are more likely to have accounts?  Why not Foundation.wiki, or Meta, or Mediawiki, or Office.wiki?  Whatamidoing (WMF) (talk) 20:36, 24 September 2014 (UTC)
 * There are SUL and LDAP authentication providers available. LDAP technically already works in Phabricator and LDAP is used in Wikimedia for wikitech and Gerrit, but we cannot yet enable LDAP in Phabricator for everybody due to file storage stuff to sort out. For SUL (which means OAuth) we cannot enable that yet either for everybody, but for other reasons. Do Foundation.wiki, or Meta, or Mediawiki, or Office.wiki use LDAP? --AKlapper (WMF) (talk) 21:01, 24 September 2014 (UTC)
 * Uhm, I realize my last sentence might come across as unfriendly (I am sorry for that) but it was meant as an honest question, as I simply don't know for some of these aforementioned wikis. --AKlapper (WMF) (talk) 21:06, 24 September 2014 (UTC)
 * I don't know anything about their setup. I know that only 3,840 accounts exist at wikitech (including 72 blocked accounts), and only about 40% of them have ever made an edit there.  That's not very many, so it means that most users will encounter account creation hassle.  Whatamidoing (WMF) (talk) 21:51, 25 September 2014 (UTC)
 * aren't our replies clear? By the time registration is open to users, Wikimedia SUL will be enabled, and 99,999% of Wikimedia users have a Wikimedia account by definition (and the remaining 0,001% should get one). :) If Wikimedia SUL goes down for whatever reason, the few people able to do something about it will have surely a wikitech-LDAP account, so they will still be able to operate. In the strange event that Wikimedia SUL was down for several hours (did this ever happen?), users could still create an account in wikitech to login to Phabricator and deal with the crisis. You can forget about wikitech-LDAP. We were hoping to enable Wikimedia SUL this week, and if we don't succeed we really really hope to have it available next week.--Qgil-WMF (talk) 06:44, 26 September 2014 (UTC)
 * Qgil-WMF, you have explained very clearly why it is highly desirable to have a second system for logging in. Why this one in particular was required now has not been addressed.  Perhaps the answer lies in André's still-unanswered question about whether MediaWiki can do LDAP?  Are SUL and LDAP mutually exclusive?  Whatamidoing (WMF) (talk) 16:17, 29 September 2014 (UTC)
 * see the discussion and conclusion at . Long story short: we want everybody to login with Wikimedia SUL, and have Wikitech's LDAP as a backup just in case SUL goes down for some reason. It is just a temporary circumstance that today LDAP is ready and SUL is not. This will be fixed soon, see and related tasks (remarkably T368 Upstream mediawiki oauth provider, the current blocker).--Qgil-WMF (talk) 07:13, 25 September 2014 (UTC)