Hi, please, everyone calm down and honesty try harder to assume faith and respect the capabilities of each other. Respect includes to avoid terminology like "to bitch", "to sneak in", "stupid" when describing each other's actions.
One good way is when you are angry about an email, step back, wait a day, calm down, and answer only then. Since this matter is important, but not urgent, there is nothing that requires quick responses. No one's going to make a decision for all of us right away, so there is no need to reply quickly and escalate. I assume Ryan didn't mean to single out the Wikidata development team. Other teams have done this as well -- the Translate extension depends on ULS, CodeEditor depends on WikiEditor, Semantic Result Formats depends on Semantic MediaWiki etc. I assume Ryan just choose Wikibase because it exemplifies the symptoms so well. Ryan, please correct me if my assumptions are wrong. The reminder of this mail has two parts, first it tries to explain the motivation of why the Wikidata dev team did things the way we did, and second, it asks this list to please resolve the underlying actual issue. First: The original message by Ryan lists the number of dependencies for Wikibase. He lists, e.g. Scribunto as an extension. The question is, how to avoid this dependency? Should we move Scribunto to core? Should we turn Scribunto and Wikibase into one extension? The same for Babel and ULS, listed as optional extensions. Another extension mentioned is Diff. Diff provides generic functionality that can be used by different extensions. It seems that in this case the suggestion that Ryan makes is to move it to core. So shall we move functionality that more than one extension depend on generally to core? One of the reasons for DataValues, Ask and some others being in their own extension is that they already are or are planned very soonish to be reused in SMW. Since it is suggested that generic functionality should be moved to core, would that include functionality shared by Wikibase and SMW? Or how else would we manage that shared code? Another reason for having separate components like the WikibaseModel or Diff is that they are not MediaWiki extensions, but pure PHP libraries. Any PHP script can reuse them. Since the WikibaseModel is not trivial, this should help with the writing of bots and scripts dealing with Wikidata data. How should we handle such components? Should they be moved to Wikibase and we require every script to depend on the whole of Wikibase, and thus MediaWiki? If you add everything needed by Wikibase into a single extension, how do you ensure that no unnecessary dependencies creep in? Is there a code-analyzer that can run as part of Jenkins that check that the architecture is not being violated, and that parts of the code to not introduce dependencies on other parts where they should not? Separating such components allows us to check this part of the architecture during CI, which is indeed extremely helpful. I would indeed be very much interested in better solutions for these questions than we currently have. As Ryan said in his thread-opening email, "For legitimate library-like extensions I have no constructive alternative, but there must be some sane alternative to this." A lot of the issues would be resolved if we had this constructive alternative. The solution will likely also help to deal with the other dependencies. I hope it is understandable that I do not consider the time of the Wikidata development well spent to replace our architecture with something else, before we have agreed on what this something else should be. Second: I would be interested in answers to the above questions. But maybe we really should concentrate on getting the actual question resolved, which has been discussed on this list several times without consensus, those that would allows us to answer the above questions trivially: how should we deal with modularity, extensions, components, etc. in MediaWiki? I hope the answer is not "throw everything in core or into monolithical extensions which do not have dependencies among each other", but let's see what the discussion will bring. Once we have this answer, we can implement the results. Until then I am not sure whether I found it productive to single the Wikidata team out in the way we are doing things. I do not think the Wikidata development team is anticipating and predetermining answers to those questions, but in order for us to continue develop we had to make some decisions for us. But we don't tell anyone else how to do their job, and we try to stick to current consensus on how to do things. And as soon as we have consensus, we will adopt. We did this previously a few times, and I don't see why we should not do it again. Cheers, Denny 2013/7/22 Jeroen De Dauw <jeroended...@gmail.com> > Hey, > > > Validator was rejected from being included in core > > I'm happy it did. The code was quite poor at that time (two years back?). > And it still is not a hallmark of great design, though certainly not below > average MW quality at this point. Regardless of that, I now think it is a > bad idea to have it in core and would not petition to have it there in the > future. > > > but now basically every extension you maintain uses it. > > Can you please look at objective reality first before making claims about > how you would like the world to be so you can bitch about it? Not only are > you overly simplifying things, you get simple facts plain wrong. > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. ~=[,,_,,]:3 > -- > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
