Hello all,
I'd just like to note that I'm really not happy with this:
On 21 December 2010 01:11, valhallasw@svn.wikimedia.org wrote:
Follow-up to r8784: introducing iwkeys
The changes by purodha seem to have some more side effects due to tight coupling inside the library code. This commit fixes some additional interwiki mess [1], but I am *uncertain* of any new introduced side- effects.
If any more issues arise, I suggest reverting purodha changes and first applying the changes in a feature branch. Or, possibly, only in the rewrite branch.
[1] http://commons.wikimedia.org/w/index.php?title=Category:Tre_kronor_af_Stockh...
I am aware there is too much tightly-coupled code in the library, which means changes like this can have consequences in an entirely different part of the framework. Combined with a lack of automated testing, making large -or even small- changes in framework code is dangerous, to say the least. Especially since the code *will* be used throughout wikipedia, possibly causing botwars and an enormous mess.
As such, I would like to suggest - *strongly* suggest - not to implement new features into trunk any more. The much cleaner rewrite should be the place to put these features. This means only bugfixes and family/language updates should go into trunk.
Comments welcome.
Best regards, Merlijn
Good morning,
2010/12/21 Merlijn van Deen valhallasw@arctus.nl
I'd just like to note that I'm really not happy with this:
The changes by purodha seem to have some more side effects due to tight coupling inside the library code. This commit fixes some additional interwiki mess [1], but I am *uncertain* of any new introduced side- effects.
I understand you. This sounds a bit unusual. My programming mind would say to revert the changes first and send them to further testing instead of patching the patches of patches in a working system. But I cannot really see the complexity of this part of the famework.
As such, I would like to suggest - *strongly* suggest - not to implement new features into trunk any more. The much cleaner rewrite should be the place to put these features. This means only bugfixes and family/language updates should go into trunk.
Oppose, in this form. The code has to change in order to make it more useable. Though I am only a user with some minor contributions to the framework, I see a couple of limits of usability, and I myself have some requests and proposals on SF (one of which is currently important), and I would be unhappy with eradicating these.
For a time, I have read on this list, that rewrite branch is ready to use.
So, if you want to develop only the rewrite in the future, the first thing to do would be to cross the Rubicon and publicly announce that rewrite is the official version, and trunk will be unsupported after a given deadline. Wikipedia.py should write a nice notice on the screen of those who don't read the list, but update their bots automatically. And your suggestion might work after a given time. To put new features only in one branch and bugfixes in the other is *equivalent* with making the first one current and official and the second one obsolete. *(But I would appreciate to see my request concerning making -search useable in pagegenerators done before all this happens. :-)))*