Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Fri, Aug 6, 2010 at 5:16 PM, Platonides wrote: > The point is, both of them are suppressed by wfSuppressWarnings... > So what can the @ be suppressed that wfSuppressWarnings may have missed? > > Unless the decision to add an @ there predates out own warning supppresion. > @ must not be used, ever. Any uses you see are wrong and should be refactored. The vast majority of offenders are lazy array index accessing: BAD PROGRAMMER: $foo = @$bar['key']; GOOD PROGRAMMER: $foo = isset( $bar['key'] ) ? $bar['key'] : null; It's a few extra keystrokes, but you're saved from using the @ to suppress *all* errors that could be occurring there--not just the possible index-does-not-exist. Better example: $foo = @$this->obj->bar['key']; If you use @, you're also suppressing that $obj might not be an object, or that $bar doesn't have a key 'key'. Another common pitfall might be: @$obj->method(); What happens if method() changes and nobody checked the callers? You're now possibly suppressing errors you never meant to suppress. What sort of errors are ok to suppress, and how do I do it? The most common (and annoying) errors that need suppression are file operation things (fopen, file_get_contents, etc), usually due to invalid permissions. If you want to hide errors here, it's ok to do something like: wfSuppressWarnings(); $t = file_get_contents( 'somefile' ); wfRestoreWarnings(); This will properly suppress and restore the warnings for you. Handy trick, if you're making directories, wfMkdirParents() handles all of this for you, so you can just check the boolean return without having to worry about possible errors. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
Marco Schuster wrote: > On Fri, Aug 6, 2010 at 1:08 AM, Platonides wrote: >> Other patches are not so fine... >>wfSuppressWarnings(); >> - session_start(); >> + @session_start(); >>wfRestoreWarnings(); >> >> >> Sure, it was for FusionForge package, but still what error would >> session_start produce that is not trapped? (I can only make an E_NOTICE >> or E_WARNING...) > It's enough to break later header(); with "Can't send header > information - headers already sent by in foo". > > Marco The point is, both of them are suppressed by wfSuppressWarnings... So what can the @ be suppressed that wfSuppressWarnings may have missed? Unless the decision to add an @ there predates out own warning supppresion. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
Fuck you asshole go use other wiki On Fri, Aug 6, 2010 at 7:49 AM, Gerard Meijssen wrote: > 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 > >> wrote: > >> On Tue, Aug 3, 2010 at 9:03 PM, Rob Lanphier 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 >> 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 > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
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 > wrote: > On Tue, Aug 3, 2010 at 9:03 PM, Rob Lanphier 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 > 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
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Fri, Aug 6, 2010 at 1:08 AM, Platonides wrote: > Other patches are not so fine... > wfSuppressWarnings(); > - session_start(); > + @session_start(); > wfRestoreWarnings(); > > > Sure, it was for FusionForge package, but still what error would > session_start produce that is not trapped? (I can only make an E_NOTICE > or E_WARNING...) It's enough to break later header(); with "Can't send header information - headers already sent by in foo". Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On 06/08/10 09:10, Platonides wrote: > My idea for a FHS-friendlier setup was based in storing the > LocalSettings for all installed wikis inside /etc/mediawiki.d, all of > them pulling from a CommonSettings.php where default overrides and > extensions affecting all installs would be stored. That's basically what it does already, but it does it by patching the setup code. I'd rather see a distributed LocalSettings.php file which pulls in the necessary sub-config files. That can be done without any changes to our source. > The update process would just need to iterate on them running update.php > > Then for the installer we could ask the user to overwrite a file with > the download, overwrite it ourselves from the web installer or create > another installer, this one to be run from command line by dpkg. > > Does anyone see a problem with that approach? The web installer should not be a part of installation from a package at all. We should just get the wiki name from debconf, use the system locale as the language, and install it with defaults otherwise. Then the user will have a working wiki after install. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
My idea for a FHS-friendlier setup was based in storing the LocalSettings for all installed wikis inside /etc/mediawiki.d, all of them pulling from a CommonSettings.php where default overrides and extensions affecting all installs would be stored. The update process would just need to iterate on them running update.php Then for the installer we could ask the user to overwrite a file with the download, overwrite it ourselves from the web installer or create another installer, this one to be run from command line by dpkg. Does anyone see a problem with that approach? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
David Gerard wrote: > On 3 August 2010 00:17, Edward Z. Yang wrote: > > >>2. Distributors roll patches without telling upstream developers who >> would happily accept them into the mainline. > > > Has anyone reported the following as Debian bugs? > > * Package maintainer not sending patches back upstream > * Package maintainer not visible and active in MediaWiki development > * Package maintainer not visible and active in MediaWiki community > support, leaving supporting his packages to the upstream > > > - d. In fact, one of their patches was sent upstream a couple of months ago and we didn't react to it. https://bugzilla.wikimedia.org/show_bug.cgi?id=24132 It's a documentation patch, fine as it is, although i'd prefer to fix that by moving dumpBackup to the new Maintenance style. Other patches are not so fine... wfSuppressWarnings(); - session_start(); + @session_start(); wfRestoreWarnings(); Sure, it was for FusionForge package, but still what error would session_start produce that is not trapped? (I can only make an E_NOTICE or E_WARNING...) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On 03/08/10 00:16, Lane, Ryan wrote: > Please Debian, keep your version of MediaWiki up to date at least to the > oldest stable release, and please send your fixes upstream when you find > unfixed bugs. Debian Stable is stable in the sense that it doesn't change very often, it's not stable in the sense of fewer bugs. If there was a way to fix this, it would have been done a long time ago. Debian is a weird, bureacratic, conservative community, somewhat inscrutable to outsiders. It reminds me of Wikipedia. On 04/08/10 02:45, Niklas Laxström wrote: > On 3 August 2010 18:14, Aryeh Gregor wrote: >> > I'm thankful that the Debian MediaWiki package at least *works*. Not >> > that the same can be said of all their packages either (OpenSSL, >> > anyone?). Maybe if we provided .debs and RPMs, people would be less >> > prone to use the distro packages. > That just creates more problems: > * bad quality distro packages > * bad quality our own packages (while we know MediaWiki, we are not > experts in packaging) > * lots of confusion Last time I looked at our Debian package, it was pretty bad. The custom patches were mostly unnecessary, or could be made unnecessary with a one-line hook, incorporated upstream. However, the worst thing about it was the fact that after you installed it, you then had to run the web-based installer, typing some very specific things into the database fields, in order to make it work. Installing the package only installs the files, and upgrading the package only upgrades the files, neither operation will touch the database. I decided that to fix the Debian package, there were two basic things that needed to happen: 1) Write a new installer, that makes it possible for dpkg to trigger DB installs and upgrades. 2) Build a relationship with the Debian maintainer, and in time, perhaps take over their job. Item 1 was my motivation to start the new-installer branch, but I didn't really get close to finishing it. Luckily some other people have picked up the ball and we might see it in 1.17, although the dpkg interface will probably have to wait until later. Item 2 would be a procedure along the lines of: * Write a new package that uses the features of the new installer. * Ask the maintainer to upload this version, explaining how awesome it is. * Integrate Debian package generation into the make-release script. * After each minor release, nag the maintainer to apply the automatically generated patches. * When they get sick of that, ask them to sponsor your request for Debian Developer status. * Upload new packages to Debian on each new release. The main targets would be Unstable, Testing and Ubuntu Universe. I think Stable is mostly unfixable and not worth bothering with. I've written a few dpkg packages for Wikimedia's custom repository. It's tedious, there's a steep learning curve, but I don't think it's beyond the capabilities of our core dev team. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Wed, Aug 4, 2010 at 7:04 PM, Aryeh Gregor wrote: > 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. Combine this with a WM-operated deb/rpm repo and make mediawiki-foobar packages for all the extensions. Using version requirements in the packages you can even ensure that only compatible stuff gets installed. Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Tue, Aug 3, 2010 at 9:03 PM, Rob Lanphier 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 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
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Wed, Aug 4, 2010 at 5:48 AM, Lane, Ryan wrote: >> Is MediaWiki such a special piece of >> software that it's impossible to build a good package? > > 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. Fair enough. Is it safe to assume that the new installer work should make proper packaging more viable? > I think it would be better if we provided the packages. If we fix our > upgrade issues, I'll be more than happy to write rpms and debs. I think this would be fantastic, so defining what bar we need to clear would be seems like a worthwhile exercise. Even if distro makers still go off and create their own derivatives, having a good reference implementation would be wonderful. I think you'd be hard pressed to find a project that doesn't complain about what packagers do (assuming they don't do their own packaging, and even then...) Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
> I'm not sure I buy this. Why is MediaWiki so special that it can't > exist inside of a package? Is MediaWiki such a special piece of > software that it's impossible to build a good package? > 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. > I think user education is going to be even more futile than package > maintainer education. The allure of running a system like Debian or > Fedora is the ability to have pre-vetted software running in a > configuration designed to work as part of a system. I'm not here to > start a debate about whether they are successful in achieving that, > but it's clearly a popular enough notion that an education effort to > counter that probably won't have much of an impact with anyone beyond > the Slackware community. > > +1 for package maintainer education (as frustrating and unproductive > as it might be thusfar) > I think it would be better if we provided the packages. If we fix our upgrade issues, I'll be more than happy to write rpms and debs. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
2005 releases were the best, I wouldn't use newer only if I have a good reason to do so. On Mon, Aug 2, 2010 at 4:16 PM, Lane, Ryan wrote: >> I haven't read all the documents, but have these researchers taken >> into account backported fixes? >> >> My gut feeling is that the "preference" for 1.12 is simply due to its >> inclusion in Debian stable [1]. The maintainer seems to be actively >> backporting security fixes [2], so while I agree that these versions >> may enjoy less community support, they should not be considered broken >> on the basis of the version number alone. >> >> This, of course, unless it is certain that some vulnerabilities are >> still present in the Debian version. If you are aware of the existence >> of such a problem, I would recommend you contact >> . Otherwise, the situation might not be as >> dangerous as it seems. >> >> On the topic of facilitating upgrades: perhaps we should emphasize the >> option to install and upgrade using SVN, which is probably very >> convenient for users that are comfortable with the command line. >> Moodle has this in the official documentation and I find it very >> useful [3]. SVN could also be handy as the backend for a user-friendly >> upgrade procedure, as it already deals with local modifications and >> such. >> > > As someone who has had their code patched by the debian team, I'd like to > take the time to bitch about this. > > Firstly, their patches are often incorrect. Secondly, though they've patched > my LDAP extension a number of times, I have *never* received a bug report or > a patch from them for something they've fixed. It is extremely annoying to > see a fix has been around that I could have used months before someone > reports a problem to me. Beyond anything else this bothers me the most. They > really need to be better community members in regards to this. Lastly, > packaging and maintaining such an old version of MediaWiki does a disservice > to us, and their users. We don't support versions of MediaWiki that old. I > understand that Debian backports security fixes for MediaWiki, but they > don't backport new features, and don't backport all bug fixes. Additionally, > Debian doesn't backport security fixes for all extensions. Not all extension > developers bother maintaining backwards compatibility, and the only possible > way to get security fixes is to upgrade MediaWiki and the extension. > > Please Debian, keep your version of MediaWiki up to date at least to the > oldest stable release, and please send your fixes upstream when you find > unfixed bugs. > > Respectfully, > > Ryan Lane > > ___ > 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
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Wed, Aug 4, 2010 at 11:03 AM, Rob Lanphier wrote: > On Tue, Aug 3, 2010 at 1:38 PM, Lane, Ryan > wrote: >> I think we should be doing education, but not for the package maintainers. >> We should try harder to inform our users that they shouldn't used distro >> maintained packages, and we should explain why. > > I'm not sure I buy this. Why is MediaWiki so special that it can't > exist inside of a package? Is MediaWiki such a special piece of > software that it's impossible to build a good package? It Can, we just want a working package, And until the providers provide this, there will be recommendations against using the packages. Someone, That for example, installs a package that has broken skins right from the get go are going to have bad impressions on MediaWiki, it won't be until they go digging to find out that they need to manually set a alias for their webserver to find it, And it won't be until someone mentions otherwise that its actually the packages fault its broken. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Tue, Aug 3, 2010 at 1:38 PM, Lane, Ryan wrote: > I think we should be doing education, but not for the package maintainers. > We should try harder to inform our users that they shouldn't used distro > maintained packages, and we should explain why. I'm not sure I buy this. Why is MediaWiki so special that it can't exist inside of a package? Is MediaWiki such a special piece of software that it's impossible to build a good package? I think user education is going to be even more futile than package maintainer education. The allure of running a system like Debian or Fedora is the ability to have pre-vetted software running in a configuration designed to work as part of a system. I'm not here to start a debate about whether they are successful in achieving that, but it's clearly a popular enough notion that an education effort to counter that probably won't have much of an impact with anyone beyond the Slackware community. +1 for package maintainer education (as frustrating and unproductive as it might be thusfar) Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
Lane, Ryan wrote: >> On 3 August 2010 18:14, Aryeh Gregor >> wrote: >>> I'm thankful that the Debian MediaWiki package at least >> *works*. Not >>> that the same can be said of all their packages either (OpenSSL, >>> anyone?). Maybe if we provided .debs and RPMs, people would be less >>> prone to use the distro packages. >> >> That just creates more problems: >> * bad quality distro packages >> * bad quality our own packages (while we know MediaWiki, we are not >> experts in packaging) >> * lots of confusion >> > > I've packaged hundreds of RPMs. It isn't difficult, and you don't need to be > an expert. It is easy enough to package the MediaWiki software. The real > problem comes with upgrades. How does the package handle this? Do we ignore > the actual maintanence/update.php portion? Do we run it? How do we handle > extensions? Package them too? Do we make a repo for all of this? How are the > extensions handled on upgrade? I had some plans for adding the needed hooks to the installer so that it could be run by a package manager in a more FHS way, store LocalSettings inside /etc, automatically run upgrade.php, etc. Then since the new installer changed how LocalSettings is provided to the user, I didn't thought further on how to adapt it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
> On 3 August 2010 18:14, Aryeh Gregor > wrote: > > I'm thankful that the Debian MediaWiki package at least > *works*. Not > > that the same can be said of all their packages either (OpenSSL, > > anyone?). Maybe if we provided .debs and RPMs, people would be less > > prone to use the distro packages. > > That just creates more problems: > * bad quality distro packages > * bad quality our own packages (while we know MediaWiki, we are not > experts in packaging) > * lots of confusion > I've packaged hundreds of RPMs. It isn't difficult, and you don't need to be an expert. It is easy enough to package the MediaWiki software. The real problem comes with upgrades. How does the package handle this? Do we ignore the actual maintanence/update.php portion? Do we run it? How do we handle extensions? Package them too? Do we make a repo for all of this? How are the extensions handled on upgrade? Having MediaWiki in a package really doesn't make much sense, unless we put a lot of effort into making it work this way. > I don't see any other way out but to reach to the packagers and get > their packages fixed. What we can do is to communicate this to our > users and try to communicate more with the packagers. We already do > the first in our IRC channel (telling users we can't support distro > packages, and that they should just download the tarball), but there > are lots of place where we don't do that yet. > > In short: education and communication, not trying to do their job. > I think we should be doing education, but not for the package maintainers. We should try harder to inform our users that they shouldn't used distro maintained packages, and we should explain why. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Tue, Aug 3, 2010 at 12:45 PM, Niklas Laxström wrote: > I don't see any other way out but to reach to the packagers and get > their packages fixed. What we can do is to communicate this to our > users and try to communicate more with the packagers. I tried that with Fedora. You can read about it here: https://bugzilla.redhat.com/show_bug.cgi?id=484855 https://fedorahosted.org/fesco/ticket/225 Result: nothing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On 3 August 2010 18:14, Aryeh Gregor wrote: > I'm thankful that the Debian MediaWiki package at least *works*. Not > that the same can be said of all their packages either (OpenSSL, > anyone?). Maybe if we provided .debs and RPMs, people would be less > prone to use the distro packages. That just creates more problems: * bad quality distro packages * bad quality our own packages (while we know MediaWiki, we are not experts in packaging) * lots of confusion I don't see any other way out but to reach to the packagers and get their packages fixed. What we can do is to communicate this to our users and try to communicate more with the packagers. We already do the first in our IRC channel (telling users we can't support distro packages, and that they should just download the tarball), but there are lots of place where we don't do that yet. In short: education and communication, not trying to do their job. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On 3 August 2010 16:14, Aryeh Gregor wrote: > I'm thankful that the Debian MediaWiki package at least *works*. Not > that the same can be said of all their packages either (OpenSSL, > anyone?). Maybe if we provided .debs and RPMs, people would be less > prone to use the distro packages. >_< IT'S A TARBALL! A TARBALL OF SOURCE CODE! THAT YOU INTERPRET! >_< - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Mon, Aug 2, 2010 at 7:06 PM, Carl (CBM) wrote: > I am not a Debian developer, and I agree that sending fixes upstream > is good. But surely you're aware that the whole point of "Debian > stable" is that it does ***not*** change to newer versions of programs > after release, apart from security fixes? Which means it doesn't get all security fixes either, because nobody announces vulnerabilities or publishes patches for unsupported MediaWiki versions. If a bug occurred only in an old version, it won't be announced. Distributions that try to pretend they can support software for years past the time the vendor stopped supporting it are probably crazy, but then, they're no more crazy than the users who ask for that behavior, and I don't think we're likely to change them. >From #wikimedia-tech a couple years ago: 080511 15:35:42 mark, why Ubuntu? 080511 15:37:03 becuase that's what we use for all new servers? :) 080511 15:39:18 mark, well, yes. What made you decide on Ubuntu? 080511 15:39:28 it's debian but with predictable release cycles As for not upstreaming patches, probably the best bet there is for us to give up and just watch the major distro bug trackers ourselves, because I doubt we're going to get the distributors ever reporting anything to us consistently. On Mon, Aug 2, 2010 at 7:17 PM, Edward Z. Yang wrote: > However, upstream developers are often guilty of ignoring a distribution's > needs, so it goes both ways. I spoke with the Fedora maintainer of MediaWiki some time ago pretty extensively about his hacks to MediaWiki, particularly the way he moved all files around without understanding what he was doing and completely broke the software. (Reportedly to the point that styles and scripts didn't work because he moved them out of the web root. Really. The Fedora wiki didn't use the Fedora MediaWiki package because it was so broken.) I suggested in some detail a better way to fix things, and offered to review any patches he wanted to submit upstream. He never submitted any. Oh well. I'm thankful that the Debian MediaWiki package at least *works*. Not that the same can be said of all their packages either (OpenSSL, anyone?). Maybe if we provided .debs and RPMs, people would be less prone to use the distro packages. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On 3 August 2010 00:17, Edward Z. Yang wrote: > 2. Distributors roll patches without telling upstream developers who > would happily accept them into the mainline. Has anyone reported the following as Debian bugs? * Package maintainer not sending patches back upstream * Package maintainer not visible and active in MediaWiki development * Package maintainer not visible and active in MediaWiki community support, leaving supporting his packages to the upstream - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
>> If Debian doesn't feel they should keep supported versions in their >> repos, maybe they shouldn't distribute MediaWiki. > > That is, seriously, an absurd attitude for a Mediawiki Developer to > have. It reflects a fundamental misunderstanding of the meaning of > Debian's "stable version" system. > > Note that Debian stood up to Mozilla corp. when Mozilla attempted to > stop Debian uploading security patches to stable versions [1]. Surely > Mediawiki would have much less persuasive power telling them to stop. > > I'm exiting of this discussion at this point. I've made the point I > wanted to make, compelling or not, and I'm afraid I'm drifting off > topic. > I'm not saying we should tell them to stop. They can distribute whatever they want. I'm simply saying their "stable" version is likely doing more harm than good, and that just because they can distribute something in their somewhat insane way, doesn't mean they should. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Mon, Aug 2, 2010 at 7:35 PM, Ryan Lane wrote: > Are they also backporting security fixes for all extensions as well? I would assume that Debian, ideally, applies security patches for extensions they distribute themselves. Programs a user has installed outside the Debian system are always going to be the responsibility of the user. Of course, if Debian upgraded their "stable" version of Mediawiki to the newest version, and my production server was running a custom extension that only worked with the previous version of Mediawiki that Debian called "stable", I'd be pissed. > If Debian doesn't feel they should keep supported versions in their > repos, maybe they shouldn't distribute MediaWiki. That is, seriously, an absurd attitude for a Mediawiki Developer to have. It reflects a fundamental misunderstanding of the meaning of Debian's "stable version" system. Note that Debian stood up to Mozilla corp. when Mozilla attempted to stop Debian uploading security patches to stable versions [1]. Surely Mediawiki would have much less persuasive power telling them to stop. I'm exiting of this discussion at this point. I've made the point I wanted to make, compelling or not, and I'm afraid I'm drifting off topic. - Carl [1]: http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
> I am not a Debian developer, and I agree that sending fixes upstream > is good. But surely you're aware that the whole point of "Debian > stable" is that it does ***not*** change to newer versions of programs > after release, apart from security fixes? Debian is well known for > taking the word "stable" seriously (e.g. [1]) and it's a reason people > choose them. > Are they also backporting security fixes for all extensions as well? If not, then they are doing a serious disservice to their users. Some extensions have had some *really* serious vulnerabilities. We generally mark these as such when we find them, but the warnings go away when the vulnerabilities are fixed. Unfortunately for those using old versions of MediaWiki, they may never know the extension was vulnerable for the version they are downloading. Maybe we should be more vigilant about how we mark things, but it is difficult to manage this for all extensions, especially since they aren't all code reviewed. If Debian doesn't feel they should keep supported versions in their repos, maybe they shouldn't distribute MediaWiki. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
Excerpts from Carl (CBM)'s message of Mon Aug 02 19:06:42 -0400 2010: > I am not a Debian developer, and I agree that sending fixes upstream > is good. But surely you're aware that the whole point of "Debian > stable" is that it does ***not*** change to newer versions of programs > after release, apart from security fixes? Debian is well known for > taking the word "stable" seriously (e.g. [1]) and it's a reason people > choose them. Ryan's complaint is: 1. Distributors frequently get backported patches wrong (usually due to a lack of expertise or manpower), and 2. Distributors roll patches without telling upstream developers who would happily accept them into the mainline. However, upstream developers are often guilty of ignoring a distribution's needs, so it goes both ways. Cheers, Edward ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Mon, Aug 2, 2010 at 10:16 AM, Lane, Ryan wrote: > Please Debian, keep your version of MediaWiki up to date at least to the > oldest stable release, and please send your fixes upstream when you find > unfixed bugs. I am not a Debian developer, and I agree that sending fixes upstream is good. But surely you're aware that the whole point of "Debian stable" is that it does ***not*** change to newer versions of programs after release, apart from security fixes? Debian is well known for taking the word "stable" seriously (e.g. [1]) and it's a reason people choose them. - Carl [1]: http://www.debian.org/doc/manuals/debian-faq/ch-getting.en.html#s-updatestable ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Debian packages (was MediaWiki version statistics)
> I haven't read all the documents, but have these researchers taken > into account backported fixes? > > My gut feeling is that the "preference" for 1.12 is simply due to its > inclusion in Debian stable [1]. The maintainer seems to be actively > backporting security fixes [2], so while I agree that these versions > may enjoy less community support, they should not be considered broken > on the basis of the version number alone. > > This, of course, unless it is certain that some vulnerabilities are > still present in the Debian version. If you are aware of the existence > of such a problem, I would recommend you contact > . Otherwise, the situation might not be as > dangerous as it seems. > > On the topic of facilitating upgrades: perhaps we should emphasize the > option to install and upgrade using SVN, which is probably very > convenient for users that are comfortable with the command line. > Moodle has this in the official documentation and I find it very > useful [3]. SVN could also be handy as the backend for a user-friendly > upgrade procedure, as it already deals with local modifications and > such. > As someone who has had their code patched by the debian team, I'd like to take the time to bitch about this. Firstly, their patches are often incorrect. Secondly, though they've patched my LDAP extension a number of times, I have *never* received a bug report or a patch from them for something they've fixed. It is extremely annoying to see a fix has been around that I could have used months before someone reports a problem to me. Beyond anything else this bothers me the most. They really need to be better community members in regards to this. Lastly, packaging and maintaining such an old version of MediaWiki does a disservice to us, and their users. We don't support versions of MediaWiki that old. I understand that Debian backports security fixes for MediaWiki, but they don't backport new features, and don't backport all bug fixes. Additionally, Debian doesn't backport security fixes for all extensions. Not all extension developers bother maintaining backwards compatibility, and the only possible way to get security fixes is to upgrade MediaWiki and the extension. Please Debian, keep your version of MediaWiki up to date at least to the oldest stable release, and please send your fixes upstream when you find unfixed bugs. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
