| Aklapper | |
| Feb 28 2023, 9:47 PM |
| F36885716: differential_app_config.png | |
| Mar 1 2023, 10:09 AM |
Not sure if there could be any side effects when it comes to disabling Differential.
We could also try setting Can Use Application and Default View Policy to Administrators on https://phabricator.wikimedia.org/applications/view/PhabricatorDifferentialApplication/
I wonder if Evan Priestley ever even imagined such a situation, which is somewhat post-apocalyptic, premising that Differential was the first component of Phabricator, as far as I can have seen from its history. Let's see what happens, I think.
What's the disappointing is Phabricator does not have a self-contained DevOps workflow that satisfy our demend (e.g. lacking a full-featured CI). See T217901: Evaluate Phabricator Harbormaster.
I honestly agree that GitLab is ways more simple in CI jobs and to welcome community projects, since it's generally "repository-centric", with CI specifically "container-centric". Indeed GitLab CI has a throwaway logic on your CI infrastructure.
Phabricator instead is generally "organization-centric", with CI specifically "ssh-centric". So I love that with Harbormaster I can implement low-level things directly over SSH to my bare metal hosts, without the need of any containerization. And it works very well as I tried to document at my best here:
https://en.wikibooks.org/wiki/Phabricator_Administrator%27s_Handbook/Continuous_integration
I honestly believe that 20 minutes of training in knowing both platforms could have helped to avoid to share less superficial feedbacks from T217901. And I honestly think that maintaining Phabricator in a "non-usual" way with a core component disabled could just create a more complicated environment for the people who see Phabricator, knows Phabricator, land on Phabricator, they would like to use it /without/ the need of any external tool, and instead will be now forced to do avoid native workflows and adopt external tools.
In short, I strongly don't agree to ban the community from using Phabricator to its potential, even if they are 2 users.
Instead, I would suggest to concentrate in migrating the well-known core MediaWiki components from the proprietary BitBucket platform, and bring them to GitLab. BitBucket is a serious underestimated issue, causing true dispersion, slowdown in the development of crucial components, and that causes an extra alien workflow involving truly alien platforms.
Lets keep this task on topic and in its scope which is disabling Differential.
Soapboxing about migrating everything to Gitlab or not has has already occurred else and that has been the chosen direction.
What I mean is, please create a parent task like "Unifying development tools" or whatever can help in clarifying the purpose here (now it's not really evident from the Task description). I suggest this since, then, I would like to create a sub-task called Abandon Bitbucket™ to try to help in following the chosen direction.
Indeed. Sorry for that! I added https://www.mediawiki.org/wiki/GitLab_consultation (from 30 months ago) to the task description.
I would like to create a sub-task called Abandon Bitbucket™ to try to help in following the chosen direction.
Wikimedia does not host a Bitbucket instance. :)
Thanks but the mentioned GitLab page does not explain the purpose of this Task, as far as I can see. That page describes very well the benefits of GitLab, the disadvantages of Gerrit, and it does not cover why somebody should disable a core component of WMF Phabricator. This task is still with an unclear background purpose, for me. And it's very difficult to contribute in any way for me in this discussion without understanding the mentioned wider "direction".
Wikimedia does not host a Bitbucket™ instance
It seems you mean the direction is "Disable WMF services that are little used". This seems more an opinion than a direction, since AFAIK the whole discussion always has been about "avoiding tool dispersion" as I can understand from WMF blog posts from @zeljkofilipin (I'm not able to find that article now).
Last months three people still used Differential. We shall not have four different places (Gerrit, GitHub, Differential, GitLab) where code review may take place to confuse the hell out of new technical contributors, but ideally one place (GitLab) in the long run. Thus we should switch off Differential.
We mention GitHub since WMF has a GitHub "instance" (?) - Trust me, I ask this since I just don't truly understand why the whole purpose is not involving in any way Bitbucket™ but involves GitHub.
I mention Github because some code repos are canonically hosted on Github. And the canonical (= not-mirrored) repo location defines where the code review of patches happens for that repo.
Why do you repeatedly mention Bitbucket? I cannot follow why that is mentioned.
Yep. I mention Bitbucket since, from the perspective of a newcomer, it's surely a primary tool at the moment, and this is problematic. I will expand such discussion there:
I landed here again and I admit that this makes so sad, frustrated and confused. Apologies for my emotional context but I see this Task like, someone wants to shoot a minority, because their workflow bothers the majority.
Again, thank you all, for stop mentioning the "GitLab consultation" in unclear non-punctual ways, to justify invasive and honestly overbearing actions like the kill of core components as Differentials is - that nothing has to do with GitLab adoption, does not impede GitLab adoption, and surely "does not impede new Wikimedia contributors" that can just concentrate in contributing in already-existing repositories that are in other places.
Feel free to reopen after it's possible to discuss a clear, neutral and non-biased reason (e.g. not from people that hates Differentials, not from people that hates the learning curve of Differentials, not from people that never adopted Differentials in production successfully, not from people that works in Wikimedia Foundation and that is in charge of documenting internal tools) (for example: welcome independent volunteers, welcome stakeholders from other Wikimedia Chapters) in order to seriously discuss this, understand the risks, understanding that this is an invasive request.
Again, some community tools die just because there is no maintenance, or something and this is OK. But here, we want to kill an actively developed tool (since https://we.phorge.it/ exists) only because the majority want that. As if this "niche workflow" could jeopardize all other workflows. That doesn't make sense at all, and again, even if true, it's not one of the good reasons to kill active tools loved by niche volunteers.
Since I don't like negative feedback, my proactive proposed solution is just:
→ Stop promoting Differentials in Wikimedia Foundation (good news: we have already done it - so, everyone is happy)
I kindly ask to respect this tool, respect this workflow, respect its community (that all the known metrics already indicate as killed successfully - fantastico!) and just go ahead with GitLab if you love it, or go ahead with Gerrit if you love it, and ignoring this component if you want to ignore it.
fyi, regardless of how one feels about differential, there are already no more active repositories on Phabricator.
And just in general we don't think it's good to have too many different places for storing git repos. If it was for my personal opinion we would stop supporting github too.
@valerio.bozzolan: For which code repositories hosted on Wikimedia Phabricator do you use currently Differential for code review?
I may sound like a broken record: We shall not maintain and host three code review tools (plus GitHub). See the parent task.
someone wants to shoot a minority, because their workflow bothers the majority.
This does not consider future contributors (sampling bias) going through if/then/else contribution guides and trying not to get confused...