[opensuse-wiki] Update to 1.16

newer
[opensuse-wiki] Some problems in...

older
Re: [opensuse-wiki] Translations...

Matthew Ehle

20 Sep 2010 20 Sep '10

22:52

Hello, I have update enstage, languagestage, and dewikistage to the 1.16 release. Also, I have updated all extensions to their latest version. I have played around a bit, and everything appears to be working OK. I will be working on performance testing this new release, as it has a couple of tuning options available. In the meantime, could all of you who have access to the staging wikis conduct a user acceptance test? Although this update is not nearly as major as the one done back in November, a few things may not be working as intended, especially extensions. Thomas, you are listed as the UAT approver in Clarity, so I am really looking to you to give the final approval on this release. As soon as I get that, I will copy over the latest skin updates and completely overwrite the wiki.o.o directory in SVN. I can then check that out onto the production server and use my migration script to update the individual wikis. Speaking of migration, who is giving the final word on which wikis to move over to the new system? I see some requests from individuals, but I am still not hearing any consensus. You can leave it up to me if you want, but I will be liable to just update everything in place ; ) -Matt

Attachments:

attachment.htm (text/html — 1.6 KB)

Show replies by date

Rajko M.

21 Sep 21 Sep

03:42

New subject: [opensuse-wiki] Translations (Update to 1.16)

On Monday 20 September 2010 17:52:46 Matthew Ehle wrote:

...

Speaking of migration, who is giving the final word on which wikis to move over to the new system? I see some requests from individuals, but I am still not hearing any consensus. You can leave it up to me if you want, but I will be liable to just update everything in place ; )

I agree that small wikies should be updated in place, or they can use http://languages.opensuse.org (lang.o.o) as place for initial translation. It would be much easier for me to help if all would be in one place. Russian translators already translate pages in lang.o.o. That tells enough that they just wait http://ru.opensuse.org update, to jump there and start real work. Portuguese wiki http://pt.opensuse.org is smaller one. Carlos posted here on the wiki list that they need update, so that they can start translating. Thread: "some help with Portuguese wiki page" Jean is the one that created http://fr.opensuse.org so I consider that he speaks for French team. He posted request to this list. Thread: "French wiki update" Greek wiki http://el.opensuse.org was listed as candidate for removal when Efstathios Iosifidis, the guy that requested update, came forward on the marketing ML. He was informed about options, so he requested update. I sent email to the last known address of Freek de Kruijf about NL wiki http://nl.opensuse.org . I hope to get answer fast. I guess that I missed to be more active, like with NL wiki, with the rest that showed some signs of activity. It is not good that wiki operators are not subscribed to this list. This is not opensuse-wiki-en ML. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Thomas Schmidt

09:16

On 21.09.2010 00:52, Matthew Ehle wrote:

...

Hello, I have update enstage, languagestage, and dewikistage to the 1.16 release. Also, I have updated all extensions to their latest version. I have played around a bit, and everything appears to be working OK. I will be working on performance testing this new release, as it has a couple of tuning options available. In the meantime, could all of you who have access to the staging wikis conduct a user acceptance test? Although this update is not nearly as major as the one done back in November, a few things may not be working as intended, especially extensions.

It seems the inputbox extension lost some modifications I did to permit bugzilla searches.

...

Thomas, you are listed as the UAT approver in Clarity, so I am really looking to you to give the final approval on this release. As soon as I get that, I will copy over the latest skin updates and completely overwrite the wiki.o.o directory in SVN. I can then check that out onto the production server and use my migration script to update the individual wikis.

Stage seems fine to me. Could we do a diff of our current codebase against 1.15 to see if we have changes in mediawiki files? Greetings -- Thomas Schmidt (tom [at] opensuse.org) openSUSE Boosters Team "Don't Panic", Douglas Adams (1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Matthew Ehle

15:04

...

It seems the inputbox extension lost some modifications I did to permit bugzilla searches.

Could you tell me where the modified code is, so I can patch the newest inputbox extension with it?

...

Stage seems fine to me. Could we do a diff of our current codebase against 1.15 to see if we have >changes in mediawiki files? The only one I know of is in index.php for the automatic login piece, but nothing else should be patched. If you really want, I can take some time to try a diff, but it could be a bit complicated.

Rajko, So if I have this right... ru, pt, fr, and el should all be updated in place? If so, I can roll them into this 1.16 update.

Freek de Kruijf

15:21

Op dinsdag 21 september 2010 17:04:31 schreef Matthew Ehle:

...

...
It seems the inputbox extension lost some modifications I did to permit bugzilla searches.

Could you tell me where the modified code is, so I can patch the newest inputbox extension with it?

...
Stage seems fine to me. Could we do a diff of our current codebase against 1.15 to see if we have >changes in mediawiki files?

The only one I know of is in index.php for the automatic login piece, but nothing else should be patched. If you really want, I can take some time to try a diff, but it could be a bit complicated.

Rajko, So if I have this right... ru, pt, fr, and el should all be updated in place? If so, I can roll them into this 1.16 update.

Maybe nl as well, I am awaiting an answer from Rajko. -- fr.gr. Freek de Kruijf Dutch translator -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Matthew Ehle

16:13

...

...
...
...
Freek de Kruijf 9/21/2010 9:21 AM >>> Op dinsdag 21 september 2010 17:04:31 schreef Matthew Ehle: It seems the inputbox extension lost some modifications I did to permit bugzilla searches.

Could you tell me where the modified code is, so I can patch the newest inputbox extension with it?

...
Stage seems fine to me. Could we do a diff of our current codebase against 1.15 to see if we have >changes in mediawiki files?

The only one I know of is in index.php for the automatic login piece, but nothing else should be patched. If you really want, I can take some time to try a diff, but it could be a bit complicated.

Rajko, So if I have this right... ru, pt, fr, and el should all be updated in place? If so, I can roll them into this 1.16 update.

Maybe nl as well, I am awaiting an answer from Rajko.

They are upgraded on stage now. It looks like my little update script works for moving the old wikis onto the new system as well : )

Rajko M.

22 Sep 22 Sep

01:02

On Tuesday 21 September 2010 10:21:00 Freek de Kruijf wrote:

...

Op dinsdag 21 september 2010 17:04:31 schreef Matthew Ehle: ...

...
Rajko, So if I have this right... ru, pt, fr, and el should all be updated in place? If so, I can roll them into this 1.16 update.

Maybe nl as well, I am awaiting an answer from Rajko.

I'll answer here as part of the answer is applicable for any wiki. After quick browsing I found that many out of 878 pages in Special:PopularPages are just links to English wiki, so I would consider update in place as better alternative to procedure we did with en.opensuse.org (as explained in the bug report). The idea to upload basic set of English pages and files like in http://languages.opensuse.org is good. It is valid for any wiki that will be updated, so we would probably need help of Matthew's server side magic to speed that up, but we (more or less me) have to provide list of articles and files to move, as well as translation of custom namespaces that we created. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Christian Boltz

21 Sep 21 Sep

18:27

Hello, on Dienstag, 21. September 2010, Matthew Ehle wrote:

...

...
It seems the inputbox extension lost some modifications I did to permit bugzilla searches.

Could you tell me where the modified code is, so I can patch the newest inputbox extension with it? [...] If you really want, I can take some time to try a diff, but it could be a bit complicated.

BOFH answer: you are using the wrong version control system for the wiki. OK, I'll have to explain this... ;-) The easiest way is to use a SVN checkout directly from the svn.mediawiki.org server (branches/REL1_16/phase3 aka 1.16 branch). You can then just run a "svn diff" and see what was changed in the local copy. The same works for the extensions - check them out from svn.mediawiki.org and later just run a "svn diff". I'm using this method for the wikis I have on my server [1] and it makes maintenance much easier than unpacking tarballs ;-) A minor update means "svn up", a version update is a "svn switch" to the branch of the new release. And most important: Both keep my local changes without any additional work (except if they conflict with upstream changes). Of course this means that you can't put everything in the openSUSE SVN because that conflicts with the SVN informations from svn.mediawiki.org. You could instead use something else (for example git) and check in the whole SVN tree including the .svn directories. You can also do some SVN magic with vendor branches. http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html is a good explanation. But IMHO using another VCS on top of the upstream SVN tree is easier. (Well, at least if you know both VCS good enough. If you are a SVN god, vendor branches are the way to go of course ;-) Regards, Christian Boltz [1] The wiki that I mentioned several times when discussing various extensions is http://www.hortipendium.de - targeted at professional, german-speaking ;-) gardeners, but also useful for your garden at home. --

...

Was ist das, "Nacht"? Das ist der Zeitraum, in dem Du effektiv administrieren kannst. Weil anscheinend die User alle total faul sind, und sich ausgeloggt haben. [Wilfried Kramer] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Matthew Ehle

22 Sep 22 Sep

20:36

...

...
...
...
Christian Boltz 9/21/2010 12:27 PM >>> Hello,

on Dienstag, 21. September 2010, Matthew Ehle wrote:

...
...
It seems the inputbox extension lost some modifications I did to permit bugzilla searches.

Could you tell me where the modified code is, so I can patch the newest inputbox extension with it? [...] If you really want, I can take some time to try a diff, but it could be a bit complicated.

...

BOFH answer: you are using the wrong version control system for the wiki.

OK, I'll have to explain this... ;-)

The easiest way is to use a SVN checkout directly from the svn.mediawiki.org server (branches/REL1_16/phase3 aka 1.16 branch). You can then just run a "svn diff" and see what was changed in the local copy. The same works for the extensions - check them out from svn.mediawiki.org and later just run a "svn diff".

I'm using this method for the wikis I have on my server [1] and it makes maintenance much easier than unpacking tarballs ;-) A minor update means "svn up", a version update is a "svn switch" to the branch of the new release. And most important: Both keep my local changes without any additional work (except if they conflict with upstream changes).

Of course this means that you can't put everything in the openSUSE SVN because that conflicts with the SVN informations from svn.mediawiki.org. You could instead use something else (for example git) and check in the whole SVN tree including the .svn directories.

You can also do some SVN magic with vendor branches. http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html is a good explanation. But IMHO using another VCS on top of the upstream SVN tree is easier. (Well, at least if you know both VCS good enough. If you are a SVN god, vendor branches are the way to go of course ;-)

Hmmm, this is really not a bad idea at all. We would just keep the themes and custom plugins in berlios and use the MediaWiki SVN for the rest. Can anyone think of a reason this would not work for our situation? Really, the only core file we should have to worry about is index.php, and changes on that part of the file aren't likely.

Christian Boltz

23 Sep 23 Sep

23:23

Hello, on Mittwoch, 22. September 2010, Matthew Ehle wrote:

...

Christian Boltz 9/21/2010 12:27 PM >>>

...
BOFH answer: you are using the wrong version control system for the wiki.

...

...
The easiest way is to use a SVN checkout directly from the svn.mediawiki.org server (branches/REL1_16/phase3 aka 1.16 branch). You can then just run a "svn diff" and see what was changed in the local copy. The same works for the extensions - check them out from svn.mediawiki.org and later just run a "svn diff". ... Of course this means that you can't put everything in the openSUSE SVN because that conflicts with the SVN informations from svn.mediawiki.org. You could instead use something else (for example git) and check in the whole SVN tree including the .svn directories. ... Hmmm, this is really not a bad idea at all. We would just keep the themes and custom plugins in berlios and use the MediaWiki SVN for the rest. Can anyone think of a reason this would not work for our situation?

It isn't that easy. You are missing a small, but important detail when you compare the openSUSE wiki to what I do on my server ;-) On my server, I checkout the code _directly to the document root_. One part of the checkout is the Mediawiki core, the other parts are several extensions. That's the easy part. The difference: I have no other level of version control on top of this. Well, except the nightly backup ;-) You have to do the same checkouts for the openSUSE wiki, but additionally the code of the openSUSE wiki is managed in a central version control system and deployed from there (to stage and later to the live site). This means you have two "levels" of version control - one upstream and one for openSUSE including upstream code. I'm quite sure that having everything (Mediawiki core, extensions, openSUSE-related modifications and additions) in one version control system is very important. The alternative would be to have a very difficult to maintain mix of two different SVN checkouts (+ one for every extension) on the servers. I doubt that you want to keep such a chaos in sync between staging and production servers - and some "external" people like Rajko who run an own instance of the wiki for testing purposes would also have a very hard time. You also do not want to use svn:externals because they aren't perfectly reliable - AFAIK you'll always get the latest version of the core and the extensions whenever you do a deployment/svn up. This means versions could differ between stage and production servers... If you want to use only SVN, I'd recommend vendor branches for the Mediawiki core and the extensions. However, putting the whole wiki code in another version control system (git?) would have the advantage that "svn diff" works and that you can avoid all the branch handling. Don't get me wrong - I really don't want to stop you. I'm just saying that it's a bit more difficult than it might sound at the first look ;-)

...

Really, the only core file we should have to worry about is index.php, and changes on that part of the file aren't likely.

Never say never ;-) The best way is to ask for a hook upstream, so that the openSUSE wiki could use an unmodified index.php in future versions. Regards, Christian Boltz -- Der Vergleich hinkt wie eine Schnecke mit Holzbein ;) [David Haller] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Rajko M.

24 Sep 24 Sep

00:59

On Thursday 23 September 2010 18:23:01 Christian Boltz wrote:

...

some "external" people like Rajko who run an own instance of the wiki for testing purposes would also have a very hard time.

Luckily Rajko has a different goal with his test instance, so it is not necessary to be exactly in sync with openSUSE nor upstream :) Although, when it happens that we have to fix some css problem having synced instance will be beneficial. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Matthew Ehle

23 Sep 23 Sep

15:08

...

...
...
...
Thomas Schmidt 9/21/2010 3:16 AM >>> On 21.09.2010 00:52, Matthew Ehle wrote: Hello, I have update enstage, languagestage, and dewikistage to the 1.16 release. Also, I have updated all >extensions to their latest version. I have played around a bit, and everything appears to be working OK. I will be working on performance testing this new release, as it has a couple of tuning options >available. In the meantime, could all of you who have access to the staging wikis conduct a user acceptance test? Although this update is not nearly >as major as the one done back in November, a few things may not be working as intended, especially extensions.

It seems the inputbox extension lost some modifications I did to permit bugzilla searches.

I have found the changed lines, and I have added them to the new InputBox extension. It should be working now. Thomas, provided that you are satisfied with everything else, would you mind checking off UAT in Clarity (https://clarity.innerweb.novell.com/niku/app?action=npt.overview)? This way, we can have some documentation on the deployment and I can push it live tomorrow. Thanks!

Rajko M.

25 Sep 25 Sep

23:35

On Monday 20 September 2010 17:52:46 Matthew Ehle wrote: ...

...

Speaking of migration, who is giving the final word on which wikis to move over to the new system? I see some requests from individuals, but I am still not hearing any consensus. You can leave it up to me if you want, but I will be liable to just update everything in place ; )

-Matt

It seems that updating all wikies would be actually the best thing. I found out, looking in recent changes on en.opensuse.org and following the lead, that someone is trying to update http://pl.opensuse.org , and he is pretty active in last few days. It seems that more often happens that translators are just doing the job instead going to the opensuse-wiki list and asking for permission. Probably lack of very visible information how to do things the way we think it should be done is main culprit for this :) So, the question, how expensive is to update all wikies that are initially listed for update? If it is not a money problem then it can be better to have all servers up to date, than one bento one openSUSE skin, even if we have to shut down some of them later. Opinions? -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

DenverD

26 Sep 26 Sep

00:21

Rajko M. wrote:

...

On Monday 20 September 2010 17:52:46 Matthew Ehle wrote: ...

...
Speaking of migration, who is giving the final word on which wikis to move over to the new system? I see some requests from individuals, but I am still not hearing any consensus. You can leave it up to me if you want, but I will be liable to just update everything in place ; )

-Matt

It seems that updating all wikies would be actually the best thing.

I found out, looking in recent changes on en.opensuse.org and following the lead, that someone is trying to update http://pl.opensuse.org , and he is pretty active in last few days.

It seems that more often happens that translators are just doing the job instead going to the opensuse-wiki list and asking for permission. Probably lack of very visible information how to do things the way we think it should be done is main culprit for this :) [snip]

do folks have to have ask permission to contribute? if you want to require folks to have your permission, then _lock_ all the pages and force them to come to you for permission....then, give them the keypass.. or, at least put up a big sign saying GET PERMISSION BEFORE CONTRIBUTING DenverD -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Rémy Marquis

00:55

On Sun, Sep 26, 2010 at 2:21 AM, DenverD wrote:

...

Rajko M. wrote:

...
On Monday 20 September 2010 17:52:46 Matthew Ehle wrote: ...

...
Speaking of migration, who is giving the final word on which wikis to move over to the new system? I see some requests from individuals, but I am still not hearing any consensus. You can leave it up to me if you want, but I will be liable to just update everything in place ; )

-Matt

It seems that updating all wikies would be actually the best thing.

I found out, looking in recent changes on en.opensuse.org and following the lead, that someone is trying to update http://pl.opensuse.org , and he is pretty active in last few days.

It seems that more often happens that translators are just doing the job instead going to the opensuse-wiki list and asking for permission. Probably lack of very visible information how to do things the way we think it should be done is main culprit for this :) [snip]

do folks have to have ask permission to contribute?

if you want to require folks to have your permission, then _lock_ all the pages and force them to come to you for permission....then, give them the keypass..

or, at least put up a big sign saying

GET PERMISSION BEFORE CONTRIBUTING

DenverD

Denver, could you please stop to whine continuously ? We're talking about synchronizing wiki migration/updates here, you don't need to ask permission on an open wiki. R. -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

DenverD

01:05

Rémy Marquis wrote:

...

On Sun, Sep 26, 2010 at 2:21 AM, DenverD wrote:

...
Rajko M. wrote:

...
On Monday 20 September 2010 17:52:46 Matthew Ehle wrote: ...

...
Speaking of migration, who is giving the final word on which wikis to move over to the new system? I see some requests from individuals, but I am still not hearing any consensus. You can leave it up to me if you want, but I will be liable to just update everything in place ; )

-Matt It seems that updating all wikies would be actually the best thing.

I found out, looking in recent changes on en.opensuse.org and following the lead, that someone is trying to update http://pl.opensuse.org , and he is pretty active in last few days.

It seems that more often happens that translators are just doing the job instead going to the opensuse-wiki list and asking for permission. Probably lack of very visible information how to do things the way we think it should be done is main culprit for this :) [snip] do folks have to have ask permission to contribute?

if you want to require folks to have your permission, then _lock_ all the pages and force them to come to you for permission....then, give them the keypass..

or, at least put up a big sign saying

GET PERMISSION BEFORE CONTRIBUTING

DenverD

Denver, could you please stop to whine continuously ? We're talking about synchronizing wiki migration/updates here, you don't need to ask permission on an open wiki.

you are right, you have a good hold this wiki thing...so.. -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Rajko M.

15:02

Rémy Marquis wrote:

...

On Saturday 25 September 2010 20:05:56 DenverD wrote:

...
Denver, could you please stop to whine continuously ? We're talking about synchronizing wiki migration/updates here, you don't need to ask permission on an open wiki.

you are right, you have a good hold this wiki thing...so..

If you are not happy there are few options: 1) Help us, like you started to do once upon a time; We need people. Isn't that obvious? 2) Keep stings for yourself; No one in wiki team needs them, nor deserves them. Being ironic sometimes is ok, but continuously - it irritates. If you have opinion that we did not good job, then explain why you didn't come up with a better proposal? If answer is that you have no time then consider that we don't have it either, but we did something. Far from perfect, but it is shaping as better solution that the one before. 3) Continue and see what happens; I've seen valuable people changing the skin. It is loss, but I handle that just as any other loss. Life thought me to accept them. I'm well aware that no one needs permission to edit wiki and this community in general appreciate people that are active without pushing them (just doing the job), so sentence that tells differently should be suspicious. Does it look like (sligh) irony? I hope so. Besides looking behind, if you memory still serves you (after long and successful carrier with a lot of real titles), you should remember my opinion about "mentoring session", and the rest of transition process. Not happy with every detail, but no time to search for better solutions, so accept what is on the table and do the best you can. Problem in this particular sub-thread is that due to lack of communication one wiki is not updated, and your misdirected sting did not add anything constructive to answer implicit question:"What to do to prevent this to happen?" -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

4965

Age (days ago)

4971

Last active (days ago)

List overview

Download

16 comments

7 participants

participants (7)

Christian Boltz
DenverD
Freek de Kruijf
Matthew Ehle
Rajko M.
Rémy Marquis
Thomas Schmidt