Re: [Wikitech-l] MediaWiki tarballs and the WMF
On 8 June 2012 02:32, Tim Starling tstarl...@wikimedia.org wrote: I've long believed that MediaWiki should be considered a project of the WMF, on the same level as the wikis we host. It's quite definitely on-mission: it makes this form of knowledge-spreading normal and expected. (Of course, just consider the perennial cries for WMF support from non-Wikipedia products ...) Perhaps if we included donation requests on the download and installer pages then MediaWiki might be considered worthy of some attention in its own right? A help MediaWiki, donate to WMF link next to the download button strikes me as entirely appropriate. I assume our fundraising includes some way to tell what links are on the path to a given successful donation. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update on IPv6
Anthony wikim...@inbox.org wrote: On Sat, Jun 9, 2012 at 4:29 PM, Anthony wikim...@inbox.org wrote: On Fri, Jun 8, 2012 at 9:59 AM, Strainu strain...@gmail.com wrote: 2012/6/8 Anthony wikim...@inbox.org: No one has to break the loop. The loop will break itself. Either enough people will get sick of NAT to cause demand for IPv6, or they won't. That one way of seeing things, but I fear it's a bit simplistic and naive. People won't get sick of NAT, since most of them don't know what NAT is anyway. They'll just notice that the speed sucks or that they can't edit Wikipedia because their public IP was blocked. But they won't know IPv6 is (part of) the solution unless someone tells them to, by events like the IPv6 day. Or by the ISP which provides IPv6 advertising those faster speeds or decreased privacy. Here at BestISP, we assign you a unique number that you can never change! We attach this unique number to all your Internet communications, so that every time you go back to a website, that website knows they're dealing with the same person. Switch to BestISP! 1% faster communications, and the increased ability for websites to track you! There are numerous reasons to have fixed IPv6 addresses per connection. For example, I have right now around 6 devices supporting IPv6 at home and I do connect between them internally (for example one of the is printer - my laptop prints on my printer no matter whether it is at home or somewhere else provided it has IPv6). You *DON'T* want to renumber your whole home network every time your ISP changes your IPv6 prefix. Just because some people got away with the stuff they do on the Internet because their ISP changes their IPv4 address every so and then does not mean that dynamic IPv4 address provides *any* privacy. I could argue that current scheme w/dynamic IPv4 provides less privacy in the long term for the user. One of the reasons for that is it is difficult to run your own infrastructure (like mail server, web server) on one's own residential connection and you have to rely on external (called cloud today) providers for that with obvious privacy consequences of that. The whole point of IPv6 is to give the choice not to use external providers - you become part of the cloud, not just a dumb consumer. //Saper ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update on IPv6
On 9 June 2012 21:51, Anthony wikim...@inbox.org wrote: Here at BestISP, we assign you a unique number that you can never change! We attach this unique number to all your Internet communications, so that every time you go back to a website, that website knows they're dealing with the same person. Switch to BestISP! 1% faster communications, and the increased ability for websites to track you! Whereas in the real world, IPv4 static IPs are considered a cost-extra feature, and one source of IPv6 resistance at consumer ISPs has been that they couldn't sell said cost-extra feature with it. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki tarballs and the WMF
On 7 June 2012 18:55, Chad innocentkil...@gmail.com wrote: Looking at the Ubuntu package[0], there's a *bunch* of other patches Have these all been upstreamed (some obviously have, and some are backports) [0] http://packages.ubuntu.com/quantal/web/mediawiki By the way - that's still MW 1.15. Is it too late for Ubuntu 12.10 to pull MW 1.19 from Debian? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki tarballs and the WMF
The debian import freeze for ubuntu 12.10 is at july 5th[0]. They import testing and/or unstable, and they both have 1.15. The MediaWiki 1.19 package is in experimental currently[1], but I don't really know why. Maybe ask the maintainer to push the 1.19 package to testing? [0] https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule [1] http://packages.debian.org/experimental/mediawiki On Sun, Jun 10, 2012 at 9:50 PM, David Gerard dger...@gmail.com wrote: On 7 June 2012 18:55, Chad innocentkil...@gmail.com wrote: Looking at the Ubuntu package[0], there's a *bunch* of other patches Have these all been upstreamed (some obviously have, and some are backports) [0] http://packages.ubuntu.com/quantal/web/mediawiki By the way - that's still MW 1.15. Is it too late for Ubuntu 12.10 to pull MW 1.19 from Debian? - d. ___ 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] MediaWiki tarballs and the WMF
On 06/10/2012 04:15 PM, Martijn Hoekstra wrote: The debian import freeze for ubuntu 12.10 is at july 5th[0]. ... Maybe ask the maintainer to push the 1.19 package to testing? I discussed this with them last week and that is the current plan. It is being vetted in experimental before it gets pushed to testing. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for June 04, 2012 - June 11, 2012 Status changes this week Bugs NEW : 214 Bugs ASSIGNED : 17 Bugs REOPENED : 25 Bugs RESOLVED : 130 Total bugs still open: 7916 Resolutions for the week: Bugs marked FIXED : 86 Bugs marked REMIND : 0 Bugs marked INVALID: 19 Bugs marked DUPLICATE : 10 Bugs marked WONTFIX: 6 Bugs marked WORKSFORME : 8 Bugs marked LATER : 3 Bugs marked MOVED : 0 Specific Product/Component Resolutions User Metrics New Bugs Per Component ArticleFeedbackv5 10 Site configuration 9 General/Unknown 5 Semantic MediaWiki 5 UploadWizard3 New Bugs Per Product MediaWiki 17 Wikimedia 21 MediaWiki extensions40 Security1 Huggle 1 Top 5 Bug Resolvers mtraceur [AT] member.fsf.org10 s.mazeland [AT] xs4all.nl 9 krenair [AT] gmail.com 9 jamesin.hongkong.1 [AT] gmail.com 8 santhosh.thottingal [AT] gmail.com 7 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki tarballs and the WMF
On 09/06/12 09:46, Rob Lanphier wrote: I've long mused out loud about this possibility, but I've become less certain over time that this is a good outcome based on what happened with Mozilla Messaging (spun out to work on Thunderbird, then folded back into Mozilla). The overhead of yet another organization wasn't worth it for them, and probably won't be worth it for us. The two organisations would have to compete for senior staff, instead of the time allocation being internally managed. I'm not sure who would win. That said, I think there is a structural problem here, and I'm glad Mark has started the process of making release management something that has more volunteer involvement. The needs of running the Wikimedia family of websites are strikingly different than the needs of small websites who want a simple-to-install wiki. For that matter, they are very different than the needs of large websites that need wiki software, but consider it a commodity that they don't want to think about very much, rather than as their core product. Without the concerted involvement of people who understand and are good at balancing those concerns, we'll do a poor job of serving those folks. We'll be able to empathize and guess, and probably continue to do alright, but due to human+organizational nature, it'll probably never be as great as it could be. We could do better than how we're doing now, if the WMF executive recognised it as something we can legitimately spend time on. Just because a separate standalone MediaWiki entity isn't necessarily viable, that doesn't mean that we can't figure out how to make the release process a little more community-driven, so I'm glad there seems to be momentum around outside contributors participating more actively here. The problem with community involvement is that the community is continually undermined by the WMF, which hires all the best volunteer developers and assigns them to work on things that benefit the Wikimedia wikis. Doesn't the WMF have a responsibility to contribute back to the community from which it draws so much code and talent? -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
