openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <j...@apache.org>
Subject Re: [Mwiki] New accounts by invitation only?
Date Wed, 21 Nov 2012 21:12:20 GMT
thanks for your reply.

On 21 November 2012 21:17, TJ Frazier <tjfrazier@cfl.rr.com> wrote:

> On 11/21/2012 14:24, jan iversen wrote:
>
>> having looked at the mediawiki pages, especially the amount of updates,
>> and
>> make a trial installation my my private server, I know I can cope with the
>> maintenance problems (but NOT with spam attacks, that requires more than
>> just one person).
>>
>> If the community agrees to it, using the lazy consensus, I volunteer to
>> make maintenance of the mwiki (wiki.openoffice.org).
>>
>> If nobody object  I will very fast do the proposed mysql changes:
>> - remove accounts with no contributions during the last year.
>> - removing all new users within the last 2 weeks.
>> and prepare an update to the newest version, (and as Alexandro suggest
>> have
>> a test server) which first run it on my own ubuntu, before going live.
>>
>> The big job done by just a few people to counter attach the spam attack,
>> is
>> really a GREAT JOB, and even if I do maintenance such skilled people would
>> still be needed.
>>
>> I would need a user, that has mysql root access as well as being able to
>> modify php scripts (for installing new version) and restarting apache. To
>> get that karma I would need help, since I am sure such a right is only
>> granted with PMC approval (which is the right way!!).
>>
>> The page that Rob suggest is of high value, and would be a great way of
>> having a mini-plan for what to do on the wiki.
>>
>> I have one question though, why do we have cwiki and wiki....I might be
>> the
>> only one, but I get confused where to find which information, so maybe we
>> should decide to have all information in just one wiki ??
>>
>> have a nice day/evening.
>> Jan I.
>>
>>  Jan,
>
> The urgent thing is the one-line change to block account creation, as
> shown at [1], applied to LocalSettings.php.
>
I agree totally to that.


>
> [1] <http://www.mediawiki.org/**wiki/Manual:Preventing_access#**
> Restrict_account_creation<http://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_account_creation>
> >
>
> The karma you need can only be granted by Infra. Go ahead and ask (JFDI):
> if anyone on the PMC objects, I feel certain we will hear about it.
>
I like JFDI since Rob informed me politely about its meaning. I have made a
JIRA ticket:
https://issues.apache.org/jira/browse/INFRA-5548

so if anyone disagrees now is the time.


>
> JIRA (like the Confluence wiki, "cwiki") is a proprietary product for
> which ASF has a free license. Historically, OO.o used the FOSS products
> Bugzilla and MediaWiki. I cannot speak to the virtues of JIRA, never having
> used it, but IMHO cwiki is an inferior product compared to mwiki, and
> trying to convert mwiki to cwiki (which was discussed) is an enormous and
> unrewarding project. So we didn't.
>
> To file a JIRA ticket, mouse around on the Infra web site; you'll get
> there. You will probably need your ASF name and password. I would guess
> that your user name on the Linux system underlying mwiki will be your
> Apache name.
>

On upgrades, Clayton Cornell (the maintainer under Sun/Oracle) sent me the
> following caution:
>
>  By the way, tuck this away.. it's quite important... if/when you
>> upgrade to 1.17 or higher, you really have to test it offline in a
>> staging server.  The UTF-8 implementation has been tightened up, and
>> older Wiki databases are being hit hard... in particular when there
>> are tables defined as Latin1 (the old default), with UTF-8 content.
>> When the database is exported/converted for the update to MW1.17 or
>> higher, the UTF-8 content is "converted" when the table is converted
>> from Latin1 to UTF-8.  The result is that the existing UTF-8 content
>> ends up double encoded and is basically unusable... this has broke a
>> LOT of wikis and very few people seem to know how to fix it (that
>> reminds me, I should post how to fix it somewhere).  You can avoid the
>> problem by checking up on the database prior to the upgrade and doing
>> a little tweak in the upgrade process (MySQL magic) to fix the badly
>> encoded tables... and i'm pretty sure that the OOo Wiki dB has this
>> problem.
>>
> Thanks for warning me. How does this sound to you:

When I get root access, I do the following:
1) modify localsettings.php, and inform you all.
2) copy the mysql db to my ubuntu server, and play with the scripts until
they work and I can remove users as stated in your earlier e-mails.
3) search the db for Latin1 and grep the data for UTF-8 content, when found
I change the header to UTF-8
4) test the pages locally
5) backup the production Db, and lock it for changes, after a fair warning
(where/how long)
6) upgrade the php/db on production, and update with the changed pages.
7) cross my finger, close my e-mail and hope for the best :-)
   (this was a danish joke, I will do the upgrade, at a time where I am
available).


3) I make the update local on my machine, an

>
> I have asked him to send the "MySQL magic", and will forward it.
>
> /tj/
>
> "Ask me for anything but time!" -- Napoleon
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message