Last modified: 2014-11-10 17:54:00 UTC
Move git repositories that are dependencies of wikidata to gerrit.
First of all, why? Secondly, we cannot do this without forking certain repos. Also, we already had this discussion, and esentially decided to have components that depend on MediaWiki be on Gerrit and those that don't on GitHub. Which is why I wonder why this bug appears all of a sudden. I'd like to so a good justification that holds into account the disadvantages and costs of a move for each individual component before it's moved.
(In reply to Jeroen De Dauw from comment #1) > First of all, why? Why were they not put on gerrit to begin with? 1) For consistency; it just corrects a mistake. Contributions and review can then be done in one place. 2) Because a build of stuff deployed on the WMF cluster should not need external services. 3) Github is not free software. > Secondly, we cannot do this without forking certain repos. Which ones are you thinking of? For stuff that are external libraries maintained by non-mediawiki communitites that are pulled in during a Wikidata build, a mirror on gerrit is sufficient, but lets only take a stab at that after the rest is done. > Also, we already had this discussion, and esentially decided to have > components that depend on MediaWiki be on Gerrit and those that don't on > GitHub. Which is why I wonder why this bug appears all of a sudden. Can you link to this discussion? > I'd like to so a good justification that holds into account the > disadvantages and costs of a move for each individual component before it's > moved. What are the disadvantages? I'm not aware of any. The cost is: Create gerrit repo; create phabricator project; merge any open pull requests; git push into gerrit; move over any old pull requests that can't be merged yet; move over any open bug reports; update repo URL where it is used; put old repo in deprecated state. Not that big IMHO.
+1 to moving stuff to gerrit.
Calling this issue unconfirmed is a bit insulting.
The issue were given an unconfirmed status per the comment 1. This is coherent with the following vision of a bug. NEW requires an action, UNCO requires an analysis before en action. In this case NEW requests the start of the moving processus, UNCO let the opportunity to discuss the case, for example through a RFC on mediawiki.org. Nothing insulting in that.
NEW does not prevent analysis. https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle says about UNCONFIRMED: "The status is changed to NEW when it has been verified that is indeed a MediaWiki or Wikimedia bug and when it can be reproduced." So NEW is the correct status. Beside that, do you think I didn't address the concerns in comment 1? If yes, which one?
To hijack the bug process for policies making and use a life cycle designed for technical issues will of course create this divergence of reading. Please also refrain to give opinions as objective FACT. You consider NEW is the correct status. NEW isn't the objective correct status. A sound argument for UNCO is "it hasn't been verified a Wikimedia bug, as we don't have any consensus to perform such a move'. But this discussion isn't about NEW or UNCO status. It's about moving Git repositories. Experience told us a bug tracker is a poor shop to discuss policies. Please open a RFC on mediawiki.org or discuss the issue on the relevant mailing lists. A community consensus is required to revert a current consensus. Comment 1 says "Also, we already had this discussion, and esentially decided to have components that depend on MediaWiki be on Gerrit and those that don't on GitHub".
AFAIK generally consensus in Wikimedia is to have stuff on gerrit.wikimedia.org (and mirror that to github). Do you agree? Maybe there was some special decision for Wikidata stuff. Can you point to that previous discussion? But AFAIK there was no _public_ discussion for Wikidata to deviate from the general case. I'm really interested in having access to such a discussion, as that would allow us to see what were the problems and what was tried to address them.
Re: UNCONF vs NEW: Topic will be fully obsolete in two weeks in Phab anyway. (In reply to Jan Zerebecki from comment #8) > Maybe there was some special decision for Wikidata stuff. Maybe in the WMDE office. Related: https://bugzilla.wikimedia.org/show_bug.cgi?id=62115
The problem you're trying to solve is a divergence of opinion about the more convenient and best platform do do outreach and be open to the world. GitHub allows us more easily to get feedback and allows external contributions. Wikimedia hosted applications allows to centralize and make convenient connections between the whole family of products, but created an incoming barrier. And please don't build an argumentation on the fact the previous consensus isn't visible or public or well documented. You are the one willing to change the consensus, it's your responsibility to get one. The fact the previous consensus weren't publicly and correctly documented is another issue. Now, you're using a bug report to gather fact previous discussions, and ask opinions. That should be red alert for you . I suspect your main reticence to open such a discussion is the hope we can at one point of this bug agree with you and the fact it's not big deal okay and let's do that. This isn't going to occur. Please note for example you're totally ignored by Wikidata developers after the Jeroen initial comment. Please invest the time to launch a proper discussion on mediawiki.org and notify the relevant mailing lists.
(That should be red alert for you of the need to open a discussion)
Thank you, Andre for the related bug. (In reply to Dereckson from comment #10) > Please note for example you're totally ignored by Wikidata developers after > the Jeroen initial comment. I don't think I'm being ignored :) . I have merge permissions on all the repositories relevant to this bug.
s/you/your current request
