Hi Jeroen, thanks for your proposal. It's very useful to revisit our infrastructure from time to time. Since people seem quite critical so far, we should probably have a bit more discussion
To be honest, I think that the (positive as well as negative) impact of this decision is not as big as one might believe. We have been at Sourceforge CSV initially, then moved to the MediaWiki SVN, then moved to MediaWiki git. None of this has really affected SMW development very deeply (although, to be fair, the move to MW SVN has increased contribution, but of couse we should not compare Sourceforge CSV to GitHub git when talking about contributions). To me it seems that the coordination of two source control tools seems to be a lot of work. Niklas worried about the delay this could introduce, and Nischay worried (like others at SMWCon) about the confusion of having some extensions here and others their. Could we automate this somehow? If we had an automated synchronisation of GitHub and Gerrit, then the advantages would combine and the disadvantages would vanish, right? Cheers, Markus On 02/11/13 16:20, Jeroen De Dauw wrote: > Hey, > > Thanks all for your feedback. > > Since there is apparently a good degree of apprehension on changing this > workflow, which is not all to surprising, I'll slightly alter and > reframe the proposal. > > Rather then "switching" to GitHub, we'll just have the new repo on > GitHub via which we access pull requests. The workflow on the WMF hosted > repo does not change. If things go well, we can gradually move more > activity to GitHub. > > Below I'm addressing some raised questions and concerns: > > > Are there similar plans for the SMW-related extensions? > > It is really up to the maintainers of those extensions. I'm quite > unhappy with the one-size-fits-all attitude that is quite prevalent in > the MediaWiki community. In some cases it makes sense to provide support > via GitHub, in others only accepting contributions via Gerrit is the > better approach. I personally have no concrete plans for extensions such > as Semantic Maps at present. If SMW benefits from this change, then I'll > of course be considering it. For the Wikidata project, we are moving > several PHP libraries to GitHub, some of which are SMW related. > > > Wouldn't it be confusing if some work is on Gerrit (MW and many other > extensions) while SMW work is on Github? > > The number of potential SMW developers that are using GitHub is > significantly greater then the number of MediaWiki developers. And as we > have clear empirical evidence by now, the later group is not very eager > to contribute to SMW, so why should we throw the former, under the bus? > Most interest in SMW is coming from outside the core MediaWiki > community, and for them the current workflow is not only confusing, it > is a big hassle. > > > Also worth noting would be Yuvi's Github to Gerrit Bot > http://www.mediawiki.org/wiki/User:Yuvipanda/G2G > > Relying on this mirroring infrastructure strikes me as added complexity > and more maintenance hassle. The fewer infrastructure that can break in > such a way it seriously obstructs the development process, the better. > > > Will it speed up the review process in some way? :-))) > > Not initially. However if we get more people contributing, this > situation could improve. That is all very speculative however. > > > This sounds like a potential for a mess, merging stuff into both > directions. > > Git is a distributed version control system. Distributed. In the end > there is little difference between having a branch on a repo hosted on > GitHub or a branch on my local box. The kind of merging that will happen > will not differ much from what already happens. The tree might get > deeper and more complex if people start creating forks and whatnot, > though again, this is what Git is made for. > > I anticipate no hassle whatsoever for i18n updates, as they will still > come from one source, which is the same as our current situation. > > > From my point of view, you would lose visibility of development > > Ah, this is part of the promise that everything will be so much better > if one uses a WMF hosted git repo. As I already implied above, this > promise fails to deliver. This is the case for SMW, and for most > extensions. There might be exceptions, though that does not help us. > > pre-testing (some of the extensions) at translatewiki.net > <http://translatewiki.net> as well as > having new releases with fewer translations, because translators have > less or no time to translate new strings. With this scheme it can take > two releases to fix an i18n problem and having a good translation for > it (fix in next release, translations in next+1 release). > > > Doing a push from one repo to another is not very difficult, so we can > frequently update the WMF copy of the code, and not lose the TWN > testing. Also note how this proposal does not include extensions. > Translations are important and we should certainly not throw them under > the bus. Luckily we do not have to do this in any way even if we were to > move all development to GitHub. > > Ideally TWN would directly support repos not hosted on WMF git. There > are already many MediaWiki extensions hosted only on GitHub, which are > now essentially treated as not being good enough. > > > rising barriers elsewhere > > How does SMW doing part of its development via GitHub and accepting > contributions via it make things elsewhere more difficult? > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. ~=[,,_,,]:3 > -- > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
