Hoi,
In addition to all that it makes sense to have LocalisationUpdate installed
and configured. It ensures that people who opt for another language then
English have the latest available localisations for the messages on their
wiki.
Thanks,
       GerardM

On 4 August 2010 19:04, Aryeh Gregor
<simetrical+wikil...@gmail.com<simetrical%2bwikil...@gmail.com>
> wrote:

> On Tue, Aug 3, 2010 at 9:03 PM, Rob Lanphier <ro...@robla.net> wrote:
> > +1 for package maintainer education (as frustrating and unproductive
> > as it might be thusfar)
>
> I think "education" isn't a good term for what needs to happen here.
> More like "doing the work for them".  Package maintainers might
> maintain lots of packages, and certainly don't know much about any of
> them.  Some MW developer needs to look at the popular distros, read up
> on their packaging standards, and make a MediaWiki package that a)
> meets the standards, but also b) actually works and is supported
> upstream.  Keep any packaging tools in our own SVN where that makes
> sense, so the distributor can ship software with absolutely no changes
> if they like.  And give them some contacts they can forward any
> patches to, so that hopefully that don't feel the need to accept
> patches that haven't been reviewed upstream.
>
> As I remarked on IRC, having packages as an official installation
> mechanism has nice benefits for people who don't get their code from
> distros, too.  We could set up our own official repository.  This
> would handle updates automatically, but it would do more than that
> too.  Our current installer is crippled in all sorts of ways because
> it has to run as the web user.  An installer that runs as root could
> do all sorts of handy things, particularly where permissions are an
> issue:
>
> * Enable uploads by default
> * Hide deleted images properly
> * Enable $wgCacheDirectory by default
> * Enable math by default
> * Enable clamav by default (maybe :) )
> * Enable Djvu and SVG support by default
> * Enable ImageMagick by default
> * Set up cron job to run jobs by default instead of hacky running on page
> view
>
> We'd likely want to provide packages for all the extensions in SVN
> too, somehow.  This is complicated by the fact that almost none of the
> extensions are actually released independently.  Maybe that should
> change somehow.
>
> On Wed, Aug 4, 2010 at 8:48 AM, Lane, Ryan
> <ryan.l...@ocean.navo.navy.mil> wrote:
> > It's "special". It isn't necessarily the fault of the distro or the
> package
> > maintainer for the quality of the packages. It is our fault. Upgrading is
> > unreliable for a number of reasons. It is definitely unreliable enough
> that
> > I wouldn't trust a package to do it for me, and I can't reasonably
> recommend
> > it for anyone else either.
>
> Upgrading is perfectly reliable in my experience, as long as all your
> extensions are reliable, and you upgrade them too.  If people do file
> edits, or they install weird extensions, then of course upgrades might
> break stuff.  But if you're using only well-supported extensions,
> there should be no major problems in most cases.  If there are, well,
> that's what distributions have testing for!
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to