Good morning,
2010/12/21 Merlijn van Deen <valhallasw(a)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. :-)))*
--
Bináris