Hello, Am Montag, 7. November 2011 schrieb Thomas Schmidt:
On 07.11.2011 16:18, Matthew Ehle wrote:
I know you have suggested this before. In all honesty, it doesn't really matter whether I use subversion or not, especially with the way that we have to upgrade these wikis. Getting the MW core code is the easy part. I just download, extract, and move a couple of files over.
That's still more work when compared to "svn up". And even more work if you have to modify one of the mediawiki files - you have to (remember to) patch it again at every update. (I'm quite sure index.php is modified for iChain, and MultiBoilerplate contains a patch from me to support different templates per namespace) I know that using svn doesn't change much on _this_ update - but it will save you time on the _next_ updates. Counter-question: what's the advantage of using the tarball? ;-)
The vast majority of the time is spent in downloading and installing the extensions. I use subversion for as many of them as I can, but that is suitable for maybe half of the extensions that we use.
Yes, I know there are several extensions that consist of only a single file (which is not available via SVN). OTOH, for example MultiBoilerplate is available via SVN, and we are using a modified version (with a patch from me). Just updating it with "svn up" or "svn switch" would save you lots of time here.
What would be most helpful is to re-evaluate the extensions that we are running and see if we can get rid of a couple. That would go a long way for making the upgrades easier.
As you have seen in the second half of my mail, I'm even requesting a new extension (ReplaceText) to make maintenance tasks like the CSS cleanup easier. Also the WikiEditor would be a nice feature ;-) (and will be shipped with 1.18, if I got the beta release notes right). Removing extensions is a very hard task - I had a quick look on them and think all of them still make sense. In other words: nothing to remove. The only exceptions might be SelectCategory and MultiUpload because they are already disabled ;-)
the problem we face with hosting the wiki code in git is, that our production system doesn't have git installed (only svn) and it would be quite complicated to do so because of datacenter policies etc... I think a possible solution could be githubs subversion client support[1]. I already pushed our current code state there[2], so we can evaluate if this is an option for our deployments. If Matthew confirms that this works, we can go ahead and set up the repo at https://github.com/openSUSE/wiki .
That sounds like a good idea - and brings up an interesting question: If we push SVN checkouts to git, they will include .svn directories. What will happen if you check them out using svn? ;-) (Please test this and tell me the result.)
@Christian: Could you help us doing your requested changes in the github repo once it's at its final place? You are probably the one of us with the most knowledge and experience in mediawiki,
Thanks for the flowers ;-) I should add that the wiki I'm maintaining is quite small when compared to the openSUSE wiki: only one language, less visitors (54000 total views for main page - en.opensuse.org mainpage has 1.6 million views), less than 90 registered users etc. For example, I never had to think about memcached. Oh, and I even have some more extensions [1] installed ;-)
so it would be nice if you could help us :-)
I have the "usual" problem - days with only 24 hours ;-) I'll help whenever possible, but it really depends on what other things I have on my schedule. BTW: skins/bento/css_local/style.css seems to contain a bug ;-) Line 471 is thumb tright { I'd guess there are some dots missing (".thumb .tright"), but that's only a wild guess because I don't know where this style should be used. : Regards, Christian Boltz [1] see http://hortipendium.de/Spezial:Version Just in case I shocked you: most of the additional extensions don't make sense for the openSUSE wiki for various reasons ;-) -- Wenn ich eine SuSE-CD an ein Schwein binde und dieses trete, laufen KDE & Co. auch ohne RAM recht schnell. [Robin S. Socha in de.comp.os.unix.linux.newusers] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-wiki+owner@opensuse.org