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. :-)))