Copying from #wikimedia-dev IRC (sorry) and cc'ing wikitech-l as requested:
[James_F] cscott: I think you're confused about fab.wmflabs.org. It's not meant for use. It's meant for evaluation.
[cscott] James_F: and i'm saying that unless i can use it for something i can't easily evaluate it
[greg-g] cscott: James_F crazy idea here: can some teams use it for real (I think growth is, kinda?) and export/import to a future real instance? frontend...
[cscott] greg-g: i think that's more or less the plan, but it doesn't really mean that the results will be applicable to the groups who *aren't* using it. that is, i could, for example, use the existing instance for work on the PDF backend, which is a 1-2 person project. but that doesn't mean that the results apply to how the parsoid team works.
[greg-g] cscott: of course, but it can't be on anyone else other than those people to try it and report bugs, no one can impersonate you effectively other than you.
[cscott] greg-g: i totally agree, which is why i'm arguing for a soft transition.
[greg-g] cscott: I think it's mostly semantics at this point, honestly. The difference between a soft transition and the RFC closing with "Yes, pending those blockers are addressed" are the same thing, especially since Platform (the usual suspects saddled with this kind of stuff) won't have time to actually do anything production-like any time soon with Phab.
[James_F] greg-g, cscott: I think that ultimately if we can't work out how we use gerrit and boil it down to 10 bullet points we've failed. It's a simple tool.
[cscott] greg-g: what i'm saying is i don't think it's worth closing the RFC with a "yes, but" since those bugs are all show-stoppers to Real Work right now.
[James_F] greg-g: A "soft transition" means "go make a production Phabricator instance". Which is pretty bad if we never use it properly, and don't shut down other systems.
[gwicke] we could agree to write a new RFC after actually trying it ;)
[YuviPanda] I tried setting our fab.wmflabs.org instance up for doing CR with its own hosted repositories, so we could put a few small projects there spent 3-4 hours, and got close before giving up. I can add other people to the project if they want to give it a shot :) Note that none of this is puppetized so need to be slightly extra careful
[cscott] James_F: if you want to phrase it that way, a "yes but" means, "we'll commit to transitioning to phabricator without ever having seen an instance which will actually work for us"
[greg-g] cscott: how is that different from any development problem/goal?
[cscott] James_F: i think all the extremes are bad. i don't think we should give up on phabricator. and i think it's too early to definitively commit to it. and i think we shouldn't spent 100% of the resources to make a production instance before making a decision, and I don't think we should make the decision without spending *any* of the resources. i don't think we can do a transition without some sort of integration of new and old systems, and i also agree that maintaining the old and new systems together indefinitely defeats the point.
[gwicke] fwiw, I tend to agree with cscott that it's hard to make any informed decision without actually testing it in practice
[James_F] cscott: You're throwing around dramatic terms like "blockers" without explaining what you mean. Again, please take this to wikitech-l and let's have a proper discussion.
[cscott] James_F: I'm arguing for a middle path. devote *some* resources, implement *some* interoperability, decide at *some later* point when we have a more functional instance.
-- [http://cscott.net]
Hi, please check this draft plan for the next steps in the Phabricator RfC at
https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator/Plan
This aims to be a starting point for the next round of discussion to be held online and at the Wikimedia hackathon in Zürich this weekend. Edits, questions, and feedback welcome.
On Friday, May 2, 2014, C. Scott Ananian cananian@wikimedia.org wrote:
[cscott] James_F: I'm arguing for a middle path. devote *some* resources, implement *some* interoperability, decide at *some later* point when we have a more functional instance.
This is basically the same as "Decide now on a plan identifying the the blockers, commit resources to fix them, proceed with the plan unless we get stuck with a blocker." We have identified blockers, but we are not seeing any that could not be solved with some work (from the very active upstream and/or ourselves).
We need a RfC approval to go confidently from http://fab.wmflabs.org to a production-like Wikimedia Phabricator. If that happens, the Platform Engineering team will commit resources to plan, migrate, and maintain the Phabricator instance that will deprecate five tools or more.
The Labs instance has been setup and is being fine-tuned basically on a volunteering basis, which tells a lot about Phabricator's simplicity of administration and maintenance. As it is now, it is good enough to run simple projects with a short term deadline e.g.
Chemical Markup for Wikimedia Commons http://fab.wmflabs.org/project/view/26/ (a GSoC project -- hint, hint)
Analytics-EEVS http://fab.wmflabs.org/project/board/15/
Please play with it and provide feedback. Other contributors critic with Phabricator are doing this, and it is being extremely helpful for everybody.
OK, so I'm sorry if this information is duplicated anywhere, but between the Project Management Tools review page, the Phabricator RFC, the various sub-pages of the RFC, and the content on the Phabricator instance itself, it would take me at least a couple of hours to organize my thoughts. So I'll just ask directly:
Phabricator still does not work directly with Git, right? Or has that been implemented since I last checked? If not, what is the planned workaround for Phabricator? The default workflow is to use arcanist to merge the code into Git directly. Does that handle merge conflicts? What is the rebase process?
It's not that I'm opposed to the new system. I'm just confused as to what the new workflow would actually be.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Mon, May 5, 2014 at 12:02 PM, Quim Gil qgil@wikimedia.org wrote:
Hi, please check this draft plan for the next steps in the Phabricator RfC at
https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator/Plan
This aims to be a starting point for the next round of discussion to be held online and at the Wikimedia hackathon in Zürich this weekend. Edits, questions, and feedback welcome.
On Friday, May 2, 2014, C. Scott Ananian cananian@wikimedia.org wrote:
[cscott] James_F: I'm arguing for a middle path. devote *some* resources, implement *some* interoperability, decide at *some later* point when we have a more functional instance.
This is basically the same as "Decide now on a plan identifying the the blockers, commit resources to fix them, proceed with the plan unless we get stuck with a blocker." We have identified blockers, but we are not seeing any that could not be solved with some work (from the very active upstream and/or ourselves).
We need a RfC approval to go confidently from http://fab.wmflabs.org to a production-like Wikimedia Phabricator. If that happens, the Platform Engineering team will commit resources to plan, migrate, and maintain the Phabricator instance that will deprecate five tools or more.
The Labs instance has been setup and is being fine-tuned basically on a volunteering basis, which tells a lot about Phabricator's simplicity of administration and maintenance. As it is now, it is good enough to run simple projects with a short term deadline e.g.
Chemical Markup for Wikimedia Commons http://fab.wmflabs.org/project/view/26/ (a GSoC project -- hint, hint)
Analytics-EEVS http://fab.wmflabs.org/project/board/15/
Please play with it and provide feedback. Other contributors critic with Phabricator are doing this, and it is being extremely helpful for everybody.
-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, 2014-05-05 at 12:18 -0400, Tyler Romeo wrote:
Phabricator still does not work directly with Git, right?
This topic is covered in http://fab.wmflabs.org/T207
andre
On Monday, May 5, 2014, Tyler Romeo tylerromeo@gmail.com wrote:
OK, so I'm sorry if this information is duplicated anywhere, but between the Project Management Tools review page, the Phabricator RFC, the various sub-pages of the RFC, and the content on the Phabricator instance itself, it would take me at least a couple of hours to organize my thoughts.
This is perfectly understandable. In just 2-3 weeks there has been an explosion of content in addition to all the content that was compiled before the RfC. There is a high % of signal, not much noise. Things will evetually settle.
I created https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator/versus_Bugzi... consolidate the relevant information for bug reporters. It would be useful to do the same for code contributors and reviewers, but I'm not qualified. Any volunteers?
So I'll just ask directly:
Phabricator still does not work directly with Git, right? Or has that been implemented since I last checked? If not, what is the planned workaround for Phabricator?
Relevant discussion at
Find way to use Differential with plain git (i.e.: without requiring arc) http://fab.wmflabs.org/T207
The default workflow is to use arcanist to merge the code into Git directly. Does that handle merge conflicts? What is the rebase process?
It's not that I'm opposed to the new system. I'm just confused as to what the new workflow would actually be.
On 05/05/2014 01:21 PM, Quim Gil wrote:
I created https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator/versus_Bugzi... consolidate the relevant information for bug reporters.
https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator/versus_Bugzi...
Phabricator still does not work directly with Git, right? Or has that been implemented since I last checked? If not, what is the planned workaround for Phabricator?
arc/arcanist is a wrapper around git (it also uses a Phabricator API called Conduit for a few things) that is used mainly for network operations (e.g. pushing a new patch).
git is still used for local operations, and the repo is cloneable without needing arc.
We have also talked about having a GitHub->Phabricator bridge, so drive-by contributors could make a GitHub pull request without learning arc right away.
The default workflow is to use arcanist to merge the code into Git directly. Does that handle merge conflicts? What is the rebase process?
I'm not sure exactly how conflicts are handled. However, what I do know is that you can amend a differential (which is essentially similar to a Gerrit change) with a new diff. A diff, using Phabricator terminology, is one or more commits.
So if there's a conflict, you should be able to amend locally then update the differential, similar to Gerrit. I don't know if they have a rebase button on the site similar to Gerrit.
Matt Flaschen
On 05/02/2014 03:56 PM, C. Scott Ananian wrote:
[greg-g] cscott: James_F crazy idea here: can some teams use it for real (I think growth is, kinda?) and export/import to a future real instance? frontend...
No, we're not using it for real currently. We (Growth) have talked about potentially being an early adopter, but have not committed to this yet.
Matt Flaschen
On Mon, May 5, 2014 at 10:24 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 05/02/2014 03:56 PM, C. Scott Ananian wrote:
[greg-g] cscott: James_F crazy idea here: can some teams use it for real (I think growth is, kinda?) and export/import to a future real instance? frontend...
No, we're not using it for real currently. We (Growth) have talked about potentially being an early adopter, but have not committed to this yet.
Matt Flaschen
Likewise for Analytics
wikitech-l@lists.wikimedia.org