Greetings, colleagues.
I took the PHP survey, so that part is done, but I'd like to weigh in on some of the comments I've seen in this thread. I have read all of your comments, and I agree with everything written here.
First and foremost, thanks to all who support the software and the community. This mailing list gives me a welcome word every day.
I believe that using the latest software is almost always a good idea. We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize.
Second, I'm very empathetic to anyone who experiences troubles installing products or doing upgrades. In the PHP world, we have worked hard to make the major systems (WordPress, Joomla, Drupal, Laravel, etc.,) easy to install and upgrade, and to clearly identify breaking changes from one version to the next. It's almost axiomatic that breaking changes may not occur from one release to the next. The PHP-FIG (Framework Interoperability Group) has been instrumental in guiding our thinking on this point.
PHP version 5, since PHP 5.3 has been pretty stable. I have not experienced a breaking change at all, up through PHP 5.6+. I have experienced deprecation warnings (mostly related to the antiquated MySQL extension) but these warnings can be suppressed, allowing time for developers to change to a supported database extension. This model of "deprecation before abandonment" has proved very useful for those of us who want to be up-to-date, and has given ample notice to those of us who want to remain on old software.
PHP version 7 (there is no version 6) introduces breaking changes with the removal of previously deprecated features. But it's also much faster and has better language support for some modern design and coding techniques. That said, it seems logical to me that future releases of MW should "just work" with PHP 7. There may be a good bit of work between "should" and "just works" but this seems like an enticing objective.
Some MW Extensions use PHP code that is PHP release-dependent. Finding and catching these instances before installing a breaking change is not easy. For example, consider a PHP 5.3 platform that needs the EmbedVideo extension. There is a gotcha - EmbedVideo uses a PHP array notation that is not supported in PHP 5.3. This is something that Composer is supposed to help us with. Throughout the PHP community, the universal advice is "If you're not using Composer yet, start using Composer!" Though I resisted that advice for a couple of years, I've found Composer to be one of those things like Git version control. It can save you much more than it costs you. So I would encourage anyone reading this thread to consider Composer and embrace it if possible. Perhaps greater publicity about Composer should issue forth from the Foundation? Perhaps there should be a community-standards requirement to use Composer to publish new or updated versions of MS Extensions?
And on a slight tangent, but related... A native and naked installation of MediaWiki should not be an inviting hacker target. We should be able to download and install the software without having to think too much. Then we should be able to extend update rights to our community according to our community's needs. "Built by devs for devs" is so 2005. Less configuration and more convention is a better paradigm for our future.
Again, thanks to all. I hope to see you in San Francisco,
Ray Paseur Armedia, LLC
So I have would like to update as I tend to keep my server environment as modern as possible, but unfortunately it seems that PHP7 nor PHP7-FPM are yet to be published to the Debain testing repository. Does anyone know if there are any unofficial repositories for the packages?
On Mon, 7 Dec 2015, 16:44 Ray Paseur ray.paseur@armedia.com wrote:
Greetings, colleagues.
I took the PHP survey, so that part is done, but I'd like to weigh in on some of the comments I've seen in this thread. I have read all of your comments, and I agree with everything written here.
First and foremost, thanks to all who support the software and the community. This mailing list gives me a welcome word every day.
I believe that using the latest software is almost always a good idea. We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize.
Second, I'm very empathetic to anyone who experiences troubles installing products or doing upgrades. In the PHP world, we have worked hard to make the major systems (WordPress, Joomla, Drupal, Laravel, etc.,) easy to install and upgrade, and to clearly identify breaking changes from one version to the next. It's almost axiomatic that breaking changes may not occur from one release to the next. The PHP-FIG (Framework Interoperability Group) has been instrumental in guiding our thinking on this point.
PHP version 5, since PHP 5.3 has been pretty stable. I have not experienced a breaking change at all, up through PHP 5.6+. I have experienced deprecation warnings (mostly related to the antiquated MySQL extension) but these warnings can be suppressed, allowing time for developers to change to a supported database extension. This model of "deprecation before abandonment" has proved very useful for those of us who want to be up-to-date, and has given ample notice to those of us who want to remain on old software.
PHP version 7 (there is no version 6) introduces breaking changes with the removal of previously deprecated features. But it's also much faster and has better language support for some modern design and coding techniques. That said, it seems logical to me that future releases of MW should "just work" with PHP 7. There may be a good bit of work between "should" and "just works" but this seems like an enticing objective.
Some MW Extensions use PHP code that is PHP release-dependent. Finding and catching these instances before installing a breaking change is not easy. For example, consider a PHP 5.3 platform that needs the EmbedVideo extension. There is a gotcha - EmbedVideo uses a PHP array notation that is not supported in PHP 5.3. This is something that Composer is supposed to help us with. Throughout the PHP community, the universal advice is "If you're not using Composer yet, start using Composer!" Though I resisted that advice for a couple of years, I've found Composer to be one of those things like Git version control. It can save you much more than it costs you. So I would encourage anyone reading this thread to consider Composer and embrace it if possible. Perhaps greater publicity about Composer should issue forth from the Foundation? Perhaps there should be a community-standards requirement to use Composer to publish new or updated versions of MS Extensions?
And on a slight tangent, but related... A native and naked installation of MediaWiki should not be an inviting hacker target. We should be able to download and install the software without having to think too much. Then we should be able to extend update rights to our community according to our community's needs. "Built by devs for devs" is so 2005. Less configuration and more convention is a better paradigm for our future.
Again, thanks to all. I hope to see you in San Francisco,
Ray Paseur Armedia, LLC _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Just to counter that, you are overlooking a crucial point ... On Dec 7, 2015, at 11:44 AM, Ray Paseur ray.paseur@armedia.com wrote:
I believe that using the latest software is almost always a good idea. We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize.
I hold off updates as long as at all possible, the reason being that over the last years new versions of the software have almost never come with tangible benefits to my core use. It is almost always just fixing edge-cases we don't care about and better support for things we don't use. Why? Because we have developed a workflow around the software as it existed about three years ago and there is really no reason to change that. The benefit of not using the latest is that we get to skip releases and frankly every single release just takes way, way to long to install and verify and fix across our multiple Wikis. Every release I can skip gives me half a day of my life!
The release cycles are too short. As far as I'm concerned, MediaWiki works oK, if it would do just what it does; that would be nice, and aspiring to anything else is just not what I'm interested in. The only reason why I'm constantly on the lookout for alternatives to MW are the frequent required/recommended updates.
I'm pretty sure I'm not alone in this.
Now, if a new version would come out that would autoupdate and configure itself and make sure it keeps on working with my (completely standard) extensions, that would be nice. Too modern?
Boris
I'm afraid you've got a point there, Boris. Your not alone.
Contrary to you, I 've (up to now) tried to keep everything up to date. I must now admit that the advantages of doing so are rapidly vanishing. Too often this ends in a time consuming trial and error, leading into fault messages and malfunction, hence a loss of confidence. I think I will change policies and keep things as they are until I notice a more coherent upgrade approach.
On Mon, Dec 7, 2015 at 9:34 PM, Boris Steipe boris.steipe@utoronto.ca wrote:
Just to counter that, you are overlooking a crucial point ... On Dec 7, 2015, at 11:44 AM, Ray Paseur ray.paseur@armedia.com wrote:
I believe that using the latest software is almost always a good idea.
We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize.
I hold off updates as long as at all possible, the reason being that over the last years new versions of the software have almost never come with tangible benefits to my core use. It is almost always just fixing edge-cases we don't care about and better support for things we don't use. Why? Because we have developed a workflow around the software as it existed about three years ago and there is really no reason to change that. The benefit of not using the latest is that we get to skip releases and frankly every single release just takes way, way to long to install and verify and fix across our multiple Wikis. Every release I can skip gives me half a day of my life!
The release cycles are too short. As far as I'm concerned, MediaWiki works oK, if it would do just what it does; that would be nice, and aspiring to anything else is just not what I'm interested in. The only reason why I'm constantly on the lookout for alternatives to MW are the frequent required/recommended updates.
I'm pretty sure I'm not alone in this.
Now, if a new version would come out that would autoupdate and configure itself and make sure it keeps on working with my (completely standard) extensions, that would be nice. Too modern?
Boris _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Perhaps I'm confused, but it sounds to me like there are certain classes of MediaWiki administrators out there. There's those who would prefer a hands free experience, or at the very least a point and click GUI-based administration experience and those that are would prefer a more command-line based, power-user administrative experience. Am I wrong?
Personally, I fall in the latter group. I prefer to track MediaWiki and all extensions from the command line using Git. I've never used Composer up to this point and have had no problems.
My only gripe about MediaWiki is that the development road map seems to be directed foremost by the needs of Wikimedia in support of Wikipedia. Of course, I can't really complain as it's FOSS and if I was highly motivated, I could develop the things I really want. Examples being somewhat "enterprisey", like better Oracle support, finer grained and flexible content management, etc. etc.
On Mon, Dec 7, 2015 at 3:55 PM, Francis Franck francis.franck@gmail.com wrote:
I'm afraid you've got a point there, Boris. Your not alone.
Contrary to you, I 've (up to now) tried to keep everything up to date. I must now admit that the advantages of doing so are rapidly vanishing. Too often this ends in a time consuming trial and error, leading into fault messages and malfunction, hence a loss of confidence. I think I will change policies and keep things as they are until I notice a more coherent upgrade approach.
On Mon, Dec 7, 2015 at 9:34 PM, Boris Steipe boris.steipe@utoronto.ca wrote:
Just to counter that, you are overlooking a crucial point ... On Dec 7, 2015, at 11:44 AM, Ray Paseur ray.paseur@armedia.com wrote:
I believe that using the latest software is almost always a good idea.
We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize.
I hold off updates as long as at all possible, the reason being that over the last years new versions of the software have almost never come with tangible benefits to my core use. It is almost always just fixing edge-cases we don't care about and better support for things we don't use. Why? Because we have developed a workflow around the software as it existed about three years ago and there is really no reason to change that. The benefit of not using the latest is that we get to skip releases and frankly every single release just takes way, way to long to install and verify and fix across our multiple Wikis. Every release I can skip gives me half a day of my life!
The release cycles are too short. As far as I'm concerned, MediaWiki works oK, if it would do just what it does; that would be nice, and aspiring to anything else is just not what I'm interested in. The only reason why I'm constantly on the lookout for alternatives to MW are the frequent required/recommended updates.
I'm pretty sure I'm not alone in this.
Now, if a new version would come out that would autoupdate and configure itself and make sure it keeps on working with my (completely standard) extensions, that would be nice. Too modern?
Boris _______________________________________________ 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
Bill, I think you're right there's different classes of Mediawiki administrators, but I also think you're missing the bigger picture. I use composer, the command line, etc., and find it's great. The nexus of the problem is the one you identified: the development of Mediawiki is almost 100% directed by the needs of Wikipedia, which is understandable, but also very limiting. I don't want a command GUI based administration experience for me, but I want it as an option for the mass majority of people who will move on to an easier software if they don't have it. Why should we care if people move on? Options. The more people who use Mediawiki the better the software will be become. More & better extensions will be created faster, more skins will be created, etc., the easier the software is to use. How many more plugins & extensions exist in the Joomla & Wordpress ecosystems than Mediawiki's?
Why did Mediawiki finally come out with a VisualEditor? Because of concern about the declining number of editors in Wikipedia. The mass majority of world wants to just write without concern for syntax. Creating a VisualEditor was an exercise in making it easy for new Wikipedians (I know there was a revolt about that, but that's another story). Maybe, just maybe, the same thought process that is directing the development of easier end user interfaces could be directed at making it easier for more people to use the software (maybe installing VisualEditor should be as easy as using it). The mission of Wikipedia is to empower people by giving free access to knowledge (paraphrase); shouldn't Mediawiki empower more people also (not just the technical able)?
Sent from my iPad
On Dec 7, 2015, at 1:25 PM, Bill Traynor btraynor@gmail.com wrote:
Perhaps I'm confused, but it sounds to me like there are certain classes of MediaWiki administrators out there. There's those who would prefer a hands free experience, or at the very least a point and click GUI-based administration experience and those that are would prefer a more command-line based, power-user administrative experience. Am I wrong?
Personally, I fall in the latter group. I prefer to track MediaWiki and all extensions from the command line using Git. I've never used Composer up to this point and have had no problems.
My only gripe about MediaWiki is that the development road map seems to be directed foremost by the needs of Wikimedia in support of Wikipedia. Of course, I can't really complain as it's FOSS and if I was highly motivated, I could develop the things I really want. Examples being somewhat "enterprisey", like better Oracle support, finer grained and flexible content management, etc. etc.
On Mon, Dec 7, 2015 at 3:55 PM, Francis Franck francis.franck@gmail.com wrote: I'm afraid you've got a point there, Boris. Your not alone.
Contrary to you, I 've (up to now) tried to keep everything up to date. I must now admit that the advantages of doing so are rapidly vanishing. Too often this ends in a time consuming trial and error, leading into fault messages and malfunction, hence a loss of confidence. I think I will change policies and keep things as they are until I notice a more coherent upgrade approach.
On Mon, Dec 7, 2015 at 9:34 PM, Boris Steipe boris.steipe@utoronto.ca wrote:
Just to counter that, you are overlooking a crucial point ...
On Dec 7, 2015, at 11:44 AM, Ray Paseur ray.paseur@armedia.com wrote:
I believe that using the latest software is almost always a good idea.
We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize.
I hold off updates as long as at all possible, the reason being that over the last years new versions of the software have almost never come with tangible benefits to my core use. It is almost always just fixing edge-cases we don't care about and better support for things we don't use. Why? Because we have developed a workflow around the software as it existed about three years ago and there is really no reason to change that. The benefit of not using the latest is that we get to skip releases and frankly every single release just takes way, way to long to install and verify and fix across our multiple Wikis. Every release I can skip gives me half a day of my life!
The release cycles are too short. As far as I'm concerned, MediaWiki works oK, if it would do just what it does; that would be nice, and aspiring to anything else is just not what I'm interested in. The only reason why I'm constantly on the lookout for alternatives to MW are the frequent required/recommended updates.
I'm pretty sure I'm not alone in this.
Now, if a new version would come out that would autoupdate and configure itself and make sure it keeps on working with my (completely standard) extensions, that would be nice. Too modern?
Boris _______________________________________________ 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
Apart from technical ability, there is also practical ability, tharpenator. I guess I'd be able to install VisualEditor for example, but unfortunately I'm not the owner of a server and I have no command-line access. No Parsoid, no VisualEditor
This not only makes me jealous of the "real" Wikipedia, but I'm also struggling with diminishing support for the other editors like WYSIWYG.
On Mon, Dec 7, 2015 at 11:31 PM, tharpenator@gmail.com wrote:
Bill, I think you're right there's different classes of Mediawiki administrators, but I also think you're missing the bigger picture. I use composer, the command line, etc., and find it's great. The nexus of the problem is the one you identified: the development of Mediawiki is almost 100% directed by the needs of Wikipedia, which is understandable, but also very limiting. I don't want a command GUI based administration experience for me, but I want it as an option for the mass majority of people who will move on to an easier software if they don't have it. Why should we care if people move on? Options. The more people who use Mediawiki the better the software will be become. More & better extensions will be created faster, more skins will be created, etc., the easier the software is to use. How many more plugins & extensions exist in the Joomla & Wordpress ecosystems than Mediawiki's?
Why did Mediawiki finally come out with a VisualEditor? Because of concern about the declining number of editors in Wikipedia. The mass majority of world wants to just write without concern for syntax. Creating a VisualEditor was an exercise in making it easy for new Wikipedians (I know there was a revolt about that, but that's another story). Maybe, just maybe, the same thought process that is directing the development of easier end user interfaces could be directed at making it easier for more people to use the software (maybe installing VisualEditor should be as easy as using it). The mission of Wikipedia is to empower people by giving free access to knowledge (paraphrase); shouldn't Mediawiki empower more people also (not just the technical able)?
Sent from my iPad
On Dec 7, 2015, at 1:25 PM, Bill Traynor btraynor@gmail.com wrote:
Perhaps I'm confused, but it sounds to me like there are certain classes of MediaWiki administrators out there. There's those who would prefer a hands free experience, or at the very least a point and click GUI-based administration experience and those that are would prefer a more command-line based, power-user administrative experience. Am I wrong?
Personally, I fall in the latter group. I prefer to track MediaWiki and all extensions from the command line using Git. I've never used Composer up to this point and have had no problems.
My only gripe about MediaWiki is that the development road map seems to be directed foremost by the needs of Wikimedia in support of Wikipedia. Of course, I can't really complain as it's FOSS and if I was highly motivated, I could develop the things I really want. Examples being somewhat "enterprisey", like better Oracle support, finer grained and flexible content management, etc. etc.
On Mon, Dec 7, 2015 at 3:55 PM, Francis Franck <
francis.franck@gmail.com> wrote:
I'm afraid you've got a point there, Boris. Your not alone.
Contrary to you, I 've (up to now) tried to keep everything up to date.
I
must now admit that the advantages of doing so are rapidly vanishing.
Too
often this ends in a time consuming trial and error, leading into fault messages and malfunction, hence a loss of confidence. I think I will
change
policies and keep things as they are until I notice a more coherent
upgrade
approach.
On Mon, Dec 7, 2015 at 9:34 PM, Boris Steipe boris.steipe@utoronto.ca wrote:
Just to counter that, you are overlooking a crucial point ...
On Dec 7, 2015, at 11:44 AM, Ray Paseur ray.paseur@armedia.com
wrote:
I believe that using the latest software is almost always a good idea.
We are going to upgrade eventually - why deny ourselves the benefits
of the
latest software by putting off the upgrades? The only argument in
favor of
delay would be a breaking change, and this is something that the
authors of
the software must publicize.
I hold off updates as long as at all possible, the reason being that
over
the last years new versions of the software have almost never come with tangible benefits to my core use. It is almost always just fixing edge-cases we don't care about and better support for things we don't
use.
Why? Because we have developed a workflow around the software as it
existed
about three years ago and there is really no reason to change that. The benefit of not using the latest is that we get to skip releases and
frankly
every single release just takes way, way to long to install and verify
and
fix across our multiple Wikis. Every release I can skip gives me half
a day
of my life!
The release cycles are too short. As far as I'm concerned, MediaWiki
works
oK, if it would do just what it does; that would be nice, and aspiring
to
anything else is just not what I'm interested in. The only reason why
I'm
constantly on the lookout for alternatives to MW are the frequent required/recommended updates.
I'm pretty sure I'm not alone in this.
Now, if a new version would come out that would autoupdate and
configure
itself and make sure it keeps on working with my (completely standard) extensions, that would be nice. Too modern?
Boris _______________________________________________ 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
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Bill - I think you are setting up a false dichotomy here.
I will take command-line over GUI any day. All I'm asking for is that the tool does not become the job.
B.
On Dec 7, 2015, at 4:25 PM, Bill Traynor btraynor@gmail.com wrote:
Perhaps I'm confused, but it sounds to me like there are certain classes of MediaWiki administrators out there. There's those who would prefer a hands free experience, or at the very least a point and click GUI-based administration experience and those that are would prefer a more command-line based, power-user administrative experience. Am I wrong?
Personally, I fall in the latter group. I prefer to track MediaWiki and all extensions from the command line using Git. I've never used Composer up to this point and have had no problems.
My only gripe about MediaWiki is that the development road map seems to be directed foremost by the needs of Wikimedia in support of Wikipedia. Of course, I can't really complain as it's FOSS and if I was highly motivated, I could develop the things I really want. Examples being somewhat "enterprisey", like better Oracle support, finer grained and flexible content management, etc. etc.
On Mon, Dec 7, 2015 at 3:55 PM, Francis Franck francis.franck@gmail.com wrote:
I'm afraid you've got a point there, Boris. Your not alone.
Contrary to you, I 've (up to now) tried to keep everything up to date. I must now admit that the advantages of doing so are rapidly vanishing. Too often this ends in a time consuming trial and error, leading into fault messages and malfunction, hence a loss of confidence. I think I will change policies and keep things as they are until I notice a more coherent upgrade approach.
On Mon, Dec 7, 2015 at 9:34 PM, Boris Steipe boris.steipe@utoronto.ca wrote:
Just to counter that, you are overlooking a crucial point ... On Dec 7, 2015, at 11:44 AM, Ray Paseur ray.paseur@armedia.com wrote:
I believe that using the latest software is almost always a good idea.
We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize.
I hold off updates as long as at all possible, the reason being that over the last years new versions of the software have almost never come with tangible benefits to my core use. It is almost always just fixing edge-cases we don't care about and better support for things we don't use. Why? Because we have developed a workflow around the software as it existed about three years ago and there is really no reason to change that. The benefit of not using the latest is that we get to skip releases and frankly every single release just takes way, way to long to install and verify and fix across our multiple Wikis. Every release I can skip gives me half a day of my life!
The release cycles are too short. As far as I'm concerned, MediaWiki works oK, if it would do just what it does; that would be nice, and aspiring to anything else is just not what I'm interested in. The only reason why I'm constantly on the lookout for alternatives to MW are the frequent required/recommended updates.
I'm pretty sure I'm not alone in this.
Now, if a new version would come out that would autoupdate and configure itself and make sure it keeps on working with my (completely standard) extensions, that would be nice. Too modern?
Boris _______________________________________________ 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
On Mon, Dec 7, 2015 at 7:13 PM, Boris Steipe boris.steipe@utoronto.ca wrote:
Bill - I think you are setting up a false dichotomy here.
I didn't mean to imply that those are there are only two types of MediaWiki users/administrators out there. That's definitely not true.
I will take command-line over GUI any day. All I'm asking for is that the tool does not become the job.
FWIW, my "job" has actually evolved into almost full-time MediaWiki administration. Luckily, I enjoy it.
B.
On Dec 7, 2015, at 4:25 PM, Bill Traynor btraynor@gmail.com wrote:
Perhaps I'm confused, but it sounds to me like there are certain classes of MediaWiki administrators out there. There's those who would prefer a hands free experience, or at the very least a point and click GUI-based administration experience and those that are would prefer a more command-line based, power-user administrative experience. Am I wrong?
Personally, I fall in the latter group. I prefer to track MediaWiki and all extensions from the command line using Git. I've never used Composer up to this point and have had no problems.
My only gripe about MediaWiki is that the development road map seems to be directed foremost by the needs of Wikimedia in support of Wikipedia. Of course, I can't really complain as it's FOSS and if I was highly motivated, I could develop the things I really want. Examples being somewhat "enterprisey", like better Oracle support, finer grained and flexible content management, etc. etc.
On Mon, Dec 7, 2015 at 3:55 PM, Francis Franck francis.franck@gmail.com wrote:
I'm afraid you've got a point there, Boris. Your not alone.
Contrary to you, I 've (up to now) tried to keep everything up to date. I must now admit that the advantages of doing so are rapidly vanishing. Too often this ends in a time consuming trial and error, leading into fault messages and malfunction, hence a loss of confidence. I think I will change policies and keep things as they are until I notice a more coherent upgrade approach.
On Mon, Dec 7, 2015 at 9:34 PM, Boris Steipe boris.steipe@utoronto.ca wrote:
Just to counter that, you are overlooking a crucial point ... On Dec 7, 2015, at 11:44 AM, Ray Paseur ray.paseur@armedia.com wrote:
I believe that using the latest software is almost always a good idea.
We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize.
I hold off updates as long as at all possible, the reason being that over the last years new versions of the software have almost never come with tangible benefits to my core use. It is almost always just fixing edge-cases we don't care about and better support for things we don't use. Why? Because we have developed a workflow around the software as it existed about three years ago and there is really no reason to change that. The benefit of not using the latest is that we get to skip releases and frankly every single release just takes way, way to long to install and verify and fix across our multiple Wikis. Every release I can skip gives me half a day of my life!
The release cycles are too short. As far as I'm concerned, MediaWiki works oK, if it would do just what it does; that would be nice, and aspiring to anything else is just not what I'm interested in. The only reason why I'm constantly on the lookout for alternatives to MW are the frequent required/recommended updates.
I'm pretty sure I'm not alone in this.
Now, if a new version would come out that would autoupdate and configure itself and make sure it keeps on working with my (completely standard) extensions, that would be nice. Too modern?
Boris _______________________________________________ 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
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 07/12/15 21:25, Bill Traynor wrote:
Perhaps I'm confused, but it sounds to me like there are certain classes of MediaWiki administrators out there. There's those who would prefer a hands free experience, or at the very least a point and click GUI-based administration experience and those that are would prefer a more command-line based, power-user administrative experience. Am I wrong?
Sounds like the difference between those who read individual messages and those who read digests of messages?
:-)
Gordo
mediawiki-l@lists.wikimedia.org