[MediaWiki-l] MediaWiki-l Digest, Vol 147, Issue 3

Francis Franck francis.franck at gmail.com
Wed Dec 16 08:41:57 UTC 2015

Just to extend my thanks to all Mediawiki collaborators and freelancers.
They're doing a great job

But I also want to repeat that I fully agree with Jan, Daniel and Chris. A
simple upgrade of the Maps extension brought me into a fortnight (and still
counting) of updating problems (and a wiki outage of several days). I
fortunately have some spare time (though better things to do) and a very
small wiki audience, but situations like this one would certainly
disencourage many users. I'm a user of several other packages such as
Joomla, Wordpress and Vtiger that upgrade much more easily. And yes, they
may be less complex than Mediawiki (certainly with respect to the number of
extensions) but still.

On Wed, Dec 16, 2015 at 5:02 AM, <tharpenator at gmail.com> wrote:

> Just to add to Daniel's statement, and as I said previously, the reality
> of the upgrade process, and the problems most have with it, is summed up in
> the statistics. As I recall, I think, over 70% of all wikis monitored are
> using an old, outdated version of Mediawiki. Additionally, as I recall, the
> user survey found the upgrade process is one of the top concerns of third
> party users. And consider a survey is generally only answered by people who
> feel vested into the subject. I think almost all third party users would
> gladly give a big thanks to everyone involved in the development of the
> software, but they also are speaking very loudly (counting the 70% who
> don't upgrade) with their words, & actions, that the upgrade process needs
> to be easier.
> Sent from my iPad
> > On Dec 15, 2015, at 7:34 PM, Daniel Bishop <aerosatar at gmail.com> wrote:
> >
> > I usually don't weigh in on these conversations, but I feel like I
> should speak up here too. I must also mention that, while I am not a
> developer, I *am* a reasonably technically capable user.
> >
> > All that being said: Mediawiki is hard to upgrade. That is a fact. It is
> the *only* software I have ever come across where the Official upgrade
> instructions are, essentially, "make a backup and do a completely fresh
> install, run a script, then re-customise".
> >
> > And before anyone says that isn't true, these are taken from the
> Mediawiki upgrade page:
> >
> > "You should put the decompressed tarball in a new and empty folder on
> your server. If you instead extract the new version directly on top of your
> old version, rather than in a new directory, you should follow the
> instructions described in Back up existing files and the database:
> otherwise, if you've made any customizations you may erase them in a way
> that leaves you with no reference to re-apply them from. Extracting a
> tarball over top of your live copy of MediaWiki can also leave behind files
> from the old version of MediaWiki which may interfere with the upgraded
> code. It's recommended that you unpack the new files into a new directory,
> and then apply customizations to the new directory (restoring
> LocalSettings.php, images folder, extensions, and other customizations like
> custom skins)."
> >
> > "If using Git, export the files into a clean location, and then copy the
> old customized files into the new location as described in the previous
> section."
> >
> > Simply dismissing people's completely valid comments about this with
> "your case is not normal" (and similar) is not conducive to the continued
> life of your product. (Yes, Mediawiki is essentially open-source freeware,
> but it is still a product.)
> >
> > There are a lot of software packages out there that update more
> frequently than Mediawiki does (in terms of official releases), but all of
> these have few- or no-click updates. Why does Mediawiki require a
> completely fresh install every time? Why can a new installation and update
> method not be developed?
> >
> > Jan, and many others, have made a lot of valid comments on this
> discussion. So why have they all been summarily dismissed with such...
> complete lack of consideration?
> >
> > We are not all developers. We do not all have that level of skill.
> >
> > We are not all able to devote large amounts of time to keeping the
> software 'up-to-date' with the current (rather involved) method.
> >
> > We are not asking for the more edge-case scenarios to all be covered in
> every way possible (a gap of several years *should* require/be best served
> by a fresh install).
> >
> > We are simply asking for it to be easier to upgrade our Mediawiki
> installations so that we can make use of the features, improvements and
> fixes that the developers put time into doing. (Which, incidentally, would
> also likely vastly reduce the number of edge-case installations out there.)
> >
> > The fact that this whole debate was started over a question about PHP
> versions (i.e. software dependencies) is also rather interesting.
> >
> > Regards,
> > AerosAtar
> >
> > P.S. FWIW, my install is 1.26a (559e61e) running on PHP5.6.4-4ubuntu6.3
> (fpm-fcgi).
> >
> > P.P.S. Apologies if my thoughts are not entirely coherent or do not make
> complete sense... I usually stay out of such conversations for a reason. ;)
> >
> > -----Original Message-----
> > From: MediaWiki-l [mailto:mediawiki-l-bounces at lists.wikimedia.org] On
> Behalf Of Jan Steinman
> > Sent: 15 December 2015 21:33
> > To: mediawiki-l at lists.wikimedia.org
> > Subject: Re: [MediaWiki-l] MediaWiki-l Digest, Vol 147, Issue 3
> >
> >> From: Tim Starling <tstarling at wikimedia.org>
> >
> > All good points, and yet:
> >
> >> Your case is not normal. That
> >> is the price you pay for upgrading MediaWiki as often as other people
> >> paint their houses.
> >
> > That's a useful analogy. One doesn't hire a staff painter to be on-hand,
> touching up little nicks here and there as they develop over time unless
> painting is but a small part of the operation. For most people, one waits
> until it actually needs painting.
> >
> > I have farm plants and animals to take care of, and a not-for-profit
> organization to run, and I volunteer for numerous other organizations. I
> don't have time to baby-sit a computer.
> >
> > This is not an easy thing to hear nor understand for those who spend all
> their time baby-sitting computers for a living. I know -- that was me in
> another life!
> >
> > So, one *could* say, "Hey, if we made upgrading as easy as paint drying,
> more people would keep up!"
> >
> > Or one can self-righteously blame the victim for having a life beyond
> keeping up with every little upgrade.
> >
> > (Postscript: I composed that message a week and a day ago. Then I felt
> guilty, and proceeded to go on an "upgrade binge," bringing my OS up from
> 10.6.8 to 10.10.5, which would have given me -- among other things -- PHP
> 5.6. End result: my email and website were down for a week as I struggled
> to get my server's environment back, and I never did get a working upgrade
> installed. This is coming to you from a restored backup. I feel vindicated.)
> >
> >    Jan Steinman
> >    EcoReality Co-op, http://www.EcoReality.org
> >    2152 Fulford-Ganges Road
> >    Salt Spring Island, BC V8K 1Z7 CANADA
> >    +1 250.653.2024
> >
> >
> > _______________________________________________
> > MediaWiki-l mailing list
> > To unsubscribe, go to:
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> >
> >
> > _______________________________________________
> > MediaWiki-l mailing list
> > To unsubscribe, go to:
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

More information about the MediaWiki-l mailing list