On 25 June 2015 at 23:22, Subramanya Sastry wrote:
> On behalf of the parsing team, here is an update about Parsoid, the
> bidirectional wikitext <-> HTML parser that supports Visual Editor, Flow,
> and Content Translation.
xcellent. How close are we to binning the PHP parser? (I realise
th
I didn't have anything in mind, evidently I was just vague on what the
stuff in there is and does :-)
On 26 June 2015 at 16:52, Subramanya Sastry wrote:
> On 06/25/2015 06:29 PM, David Gerard wrote:
>>
>> On 25 June 2015 at 23:22, Subramanya Sastry wrote:
>>
>>
On 2 July 2015 at 20:55, Legoktm wrote:
> I am also interested in the answer to Nemo's question about whether this
> "is the first piece of proprietary software ever entering use in the
> Wikimedia projects land?"
[not actually relevant, but since you ask ...]
First would have been Java, back
On 19 July 2015 at 19:41, Stas Malyshev wrote:
> The users should really seriously consider upgrading. 5.3 is EOL for a
> year now (which means, not even security fixes for a year) and 5.4 is
> going EOL in 2 months. If any of these sites are public-facing (and due
> to the nature of wikis, many
On 20 July 2015 at 17:03, Greg Grossmeier wrote:
>
>> If this is all their host provides, however, this will in practice
>> lead only to never-updated MediaWiki running on never-updated PHP.
> Not much anyone other than the host or the user can do about that.
> Certainly nothing we (MW devs and
On 10 August 2015 at 14:18, MZMcBride wrote:
> A proposed code of conduct like this is quite expensive to implement and
> enforce/maintain. I personally don't get the sense from reading your
> replies that you acknowledge the high cost.
In practice, EVERYONE ELSE WHO'S ADOPTED ONE hasn't found
On 11 August 2015 at 00:10, MZMcBride wrote:
> I'm curious which comparable organizations you're referring to.
Pretty much any open source project with an organisation. You've
already been referred to e.g. the Geek Feminism wiki on this point, so
if you haven't read up there already then it com
On 12 August 2015 at 23:00, Matthew Flaschen wrote:
> Enforcement is still to-be-determined.
This does need to be sorted out ahead of time. Here's today's horrible example:
http://kovalc.in/2015/08/12/harassers.html
- d.
___
Wikitech-l mailing lis
On 13 August 2015 at 22:30, rupert THURNER wrote:
> Oliver, I must be a little blind but I do not see examples of unfriendly
> behaviour in this thread.
I linked to http://kovalc.in/2015/08/12/harassers.html - perhaps that
doesn't count as unfriendly behaviour, or perhaps isn't in this
thread.
On 14 August 2015 at 22:45, Matthew Flaschen wrote:
> On 08/12/2015 06:41 PM, David Gerard wrote:
>> On 12 August 2015 at 23:00, Matthew Flaschen
>> wrote:
>>> Enforcement is still to-be-determined.
>> This does need to be sorted out ahead of time.
On 18 August 2015 at 04:15, MZMcBride wrote:
> Brian Wolff wrote:
>>I dont know about that. Viz editor is targeting ordinary tasks. Its the
>>complex things that mess stuff up.
> In most contexts, solving the ordinary/common cases is a pretty big win.
Or when it turns a complex task into a sim
I saw this today, I wonder if it's relevant to the thread:
http://www.perpendicularangel.com/2015/08/no-i-dont-trust-your-conference-without-a-code-of-conduct/
Of course we're talking about stuff beyond conferences, but it still
applies I'd think.
- d.
_
On 23 August 2015 at 03:52, Risker wrote:
> Perhaps more importantlywho were the local contacts at Hackathon 2015?
> I can't even dig that one up in the event documentation.
> A policy that exists but has no clear or visible support isn't worth the
> bytes it's written with.
+1
Don't forge
On 2 September 2015 at 07:27, Dan Garry wrote:
> On 1 September 2015 at 23:21, Federico Leva (Nemo)
> wrote:
>> Thanks. So now we'll have two unmaintained extensions, LQT and Flow.
> To quote Danny's email directly, "Flow will be maintained and supported".
> Your supposition that the extension
On 2 September 2015 at 14:51, Risker wrote:
> I want to thank the Collaboration team for taking this brave step - and
> yes, it's a brave step. The natural trajectory of large projects that don't
> quite seem to meet their promise is to keep going and going until everyone
> is burnt out, and it i
On 4 September 2015 at 01:38, Ricordisamoa wrote:
> Il 04/09/2015 01:24, Brandon Harris ha scritto:
>>> On Sep 3, 2015, at 4:06 PM, Ricordisamoa
>>> wrote:
>>> I appreciate the acknowledgement of failure.
>> I don't think that's what was said at all. You may wish to
>> re-read all of th
On 4 September 2015 at 20:12, Brandon Harris wrote:
> So it seems to me that the apps are not required to fulfill the
> mission. They feel like distractions, and - quite possibly - negatives to
> the mission (in that we can't convert Readers into Editors through the app).
It's worth
The first and last paras are particularly worth quoting:
> Earlier this year I pulled out of a conference because the organiser and I
> disagreed on code of conducts. Specifically I thought there should be one,
> and he did not. He did eventually add one, but refused to define unacceptable
> be
On 6 September 2015 at 00:11, MZMcBride wrote:
> become so enmeshed with the ultra-liberal feminist movement. I think there
It would probably be fascinating to have this technical term defined
with any specificity.
> of this content, but I can see a lot potential allies to the code of
> cond
On 7 November 2015 at 00:29, Brian Wolff wrote:
> I feel like different people want different things, and what is really
> needed is a user-centric discussion of use-cases to drive a feature
> wishlist, not any sort of discussion about implementation.
Yes. I see the rationaie in that Phabricato
I came here to post about the same problem. It appears to have broken
this morning. Did the API change again?
On 4 February 2016 at 07:33, Dr. Michael Bonert
wrote:
> In September 2014, I described an intermittent recurrent problem associated
> with the InstantCommons images.
>
> I hadn't seen th
On 4 February 2016 at 17:14, Brad Jorsch (Anomie) wrote:
> No, it was a change in the underlying image handling code that broke API
> prop=imageinfo in 1.27.0-wmf.12. Tracked as
> https://phabricator.wikimedia.org/T125804, and now resolved.
yep, working for us now. Thanks!
- d.
_
On 13 March 2016 at 20:43, Bartosz Dziewoński wrote:
> 1. Type '{{' to open template insert dialog
... this is something I never knew existed. Thank you!
> By the way, there's a list of all available keyboard shortcuts built into
> VisualEditor – it's under the '?' button on the toolbar, or u
On 5 May 2016 at 02:52, Chad wrote:
> The release branches (REL1_27) have been created for MW core, vendor,
> all extensions and all skins. MediaWiki core is now on 1.28.0-alpha.
When's the first public beta and RC? (I expected to see this on the
wiki, but it just has the final release date.)
Question about obscure historical detail: Who picked UTC as Wikimedia
time? When was this, and what was the thought process?
(the answer is almost certainly "Brion or Jimbo, early 2001, it's the
obvious choice", but I'm just curious as to details.)
- d.
_
Other projects don't do this, do they? Mozilla and LibreOffice just
list *everyone* in alphabetical order. (I'm still in the Mozilla
credits list for my work on the Mozilla 1.0 FAQ in 2002:
https://www.mozilla.org/credits/ )
On 30 May 2016 at 17:40, Jon Robson wrote:
> "I came across a patch from
On 1 August 2016 at 17:37, Marc-Andre wrote:
> We need to find a long-term view to a solution. I don't mean just keeping
> old versions of the software around - that would be of limited help. It's
> be an interesting nightmare to try to run early versions of phase3 nowadays,
> and probably requ
Don't forget to update the wiki:
https://www.mediawiki.org/wiki/Ubuntu
https://www.mediawiki.org/wiki/Debian
- d.
On 22 September 2016 at 07:44, Legoktm wrote:
> Hi,
>
> I'm very excited to announce that Debian and Ubuntu packages for
> MediaWiki are now available. These packages will follow
On 5 May 2014 22:59, Sumana Harihareswara wrote:
> Mozilla has a new Wiki Working Group[0] "to develop and drive a roadmap
> of improvements to http://wiki.mozilla.org";. They're currently on
> MediaWiki 1.19, and I predict they will want to get onto 1.23 once that
> is released (since it's going
On 5 May 2014 23:08, James Forrester wrote:
> On 5 May 2014 15:05, David Gerard wrote:
>> So ... how is 1.23 and Visual Editor?
>> * Has anyone sat down and written out how to add VE magic to a 1.23
>> tarball install?
> I do not believe so, no.
If someone could do t
On 20 May 2014 15:35, Strainu wrote:
> I've recently noticed the "Thank you" feature is only available for
> signed-in users, while anons cannot receive "thank yous". The
> anonymous users are often the ones that would need encouraging the
> most, so it would make sense to me to have this feature
rom his viewpoint.
>
> Personally, I would love to see the Thanks feature be used even more than
> it is today, as it seems like such a civilized way to show appreciation to
> each other :)
>
> Cheers,
>
>
> Fabrice
>
>
> On May 20, 2014, at 7:56 AM, David Gerar
On 5 June 2014 17:45, Zack Weinberg wrote:
> I'd like to restart the conversation about hardening Wikipedia (or
> possibly Wikimedia in general) against traffic analysis.
Or, indeed, MediaWiki tarball version itself.
- d.
___
Wikitech-l mailing li
On 5 June 2014 21:38, Jon Robson wrote:
> So from what I can see Flow pretty much does everything LiquidThreads
> does. Usually better (permalinks with LiquidThreads are one thing that
> completely bugs me - they don't always take me to the correct place)
> As I understand it there is a migration
On 6 June 2014 19:17, Brian Wolff wrote:
> Personally I have yet to see a discussion system that surpasses (or
> really even comes close) to standard talk page ":::comment here. "
> syntax. Honestly it would make me happy if we just used that in
> general.
> The exception being pages with lar
On 6 June 2014 20:12, Martijn Hoekstra wrote:
> On Fri, Jun 6, 2014 at 11:27 AM, David Gerard wrote:
>> YMMV. Wikipedia is pretty much enculturated, but RationalWiki gets
>> n00bs *all the time* who object to something on a page. You know what
>> the most frequent reply in
The key thing about Usenet and email is that the first-class entity
was the individual message - on web forums, the first-class entity is
the thread. On Usenet or email, a "thread" is something strung
together on the fly from the surviving References: headers of whatever
messages have made it as fa
On 9 June 2014 10:30, Martijn Hoekstra wrote:
> [1] i.e. a tree structure is far less powerful than what we have now to
> approximate the domain, a dag with dividable nodes probably comes closer,
> and is already fiendishly complicated to pull off on a UI level. And then I
> haven't even gone in
On 10 June 2014 15:34, Quim Gil wrote:
> * User talk pages. Do we need multithread tree discussions in our user talk
> pages? No, we don't.
And yet this is a popular use for LQT on LQT-using wikis, so will need
to be covered by Flow.
> * Regular talk pages. In most cases a section gets 2-5 re
As a third-party user: I completely concur. NDAs for security bug
access are pretty much standard, aren't they?
- d.
On 26 June 2014 15:08, Tyler Romeo wrote:
> I’ll be frank. I care a lot more about the security of MediaWiki as a
> software product,
> as well as the security of its custome
When all the bits on the sides are actually functional *and* it works
in IE, presumably :-)
On 14 July 2014 17:40, Jon Robson wrote:
> Beautiful! When can we expect to be able to enable this as a beta
> feature and try it out on Wikipedia.org?
>
>
> On Mon, Jul 14, 2014 at 5:55 AM, Risker wrote:
I *love* how typing into the search bar gives you related articles.
How are you doing that?
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Actually one annoyance I just found: I can't right-click on the talk
page link. Is there any good reason to make this a Javascript thing
rather than an ordinary link?
On 14 July 2014 23:55, David Gerard wrote:
> I *love* how typing into the search bar gives you related articles.
>
On 14 July 2014 21:06, Trevor Parscal wrote:
> I want to suggest that we give Brandon a lot of slack here, and be as
> supportive as possible.
> This is a prototype of a design, which is far better than a mockup of a
> design. It is not an actual implementation, but that is totally fine. I
> want
On 15 July 2014 22:09, Brandon Harris wrote:
> /scramble, scramble, scramble.
The curse of doing something people like!
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Where does it say it's unsupported? Some older page, talking about the
distro version? I routinely use MW from tarball on Ubuntu and it's
fine. https://www.mediawiki.org/wiki/Debian/Ubuntu
I'd personally recommend you install the prerequisites then use the
MediaWiki tarball, but the distro 1.19 in
Call it "Bob". "Bob" is always a good name.
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> but if you are a mobile developer using the REST API
every day, you need some other term to specify api.php.
Is "api.php" unsuitable for some reason?
- d
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/
On 16 August 2014 12:36, svetlana wrote:
> specifically i'd like to see links to documentation on gadget & extension
> writing
> right inside of 'gadgets' and 'beta' tabs
> somewhere in big fat banner at the bottom of each of these tabs
> 'want to add your gadget/beta feature? _learn more_ & _ge
http://threepanelsoul.com/2014/06/02/code-maintenance/
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
As a MediaWiki tarball user, I'd *love* something to rate extensions -
even to show if anyone actually uses it and cares.
On 20 August 2014 19:14, Derk-Jan Hartman wrote:
> I fully agree with Dan on that. I'd be much more interested in +/- votes on
> feedback statements. I think that might be a
So 1.19 is officially finished?
On 27 August 2014 01:02, Markus Glaser wrote:
> Hello everyone,
>
> this is a notice that on 27th August between 20:00-22:00 UTC we will release
> maintenance updates for current and legacy branches of the MediaWiki
> software. Downloads and patches will be avail
I asked this on wikimedia-l in the recent discussion with no answer. I
was wondering what the status of this feature was ...
- d.
-- Forwarded message --
From: David Gerard
Date: 1 September 2014 18:00
Subject: Re: [Wikimedia-l] Next steps regarding WMF<->community
di
On 24 September 2014 23:28, Markus Glaser wrote:
> Patch to previous version (1.19.18):
> https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.19.patch.gz
So I downloaded and applied this. gunzipped it, got this:
-rw-r--r-- 1 root root 13663 Sep 24 21:35 mediawiki-1.19.19.pa
Adding the space to includes/XmlTypeCheck.php before applying the
patch worked. Thank you!
On 26 September 2014 19:23, Grunny wrote:
> It's because there's a leading space before the tab in front of the comment
> here:
> https://git.wikimedia.org/blob/mediawiki%2Fcore.git/REL1_19/includes%2FXmlTy
So how much broken Lua is out there in the wild on WMF wikis?
On 29 September 2014 01:17, Jackmcbarn wrote:
> Scribunto has an option to allow code to be saved even if it contains
> syntax errors that prevent it from ever working. The original reason for
> this feature was to make it more conveni
On 17 October 2014 19:04, Mark Bergsma wrote:
> If you see or hear about anyone having issues connecting to our sites
> over HTTPS or logging in, please direct them at the link above, and
> urge them to upgrade their software. Unfortunately due to the nature
> of HTTPS we're not able to provide a
On 23 October 2014 16:16, Jeroen De Dauw wrote:
> I've looked at the code and it's quality of most of these projects at some
> point in the last two years, and have to say this graph is much in line
> with my impressions. And with what the "knowledgeable" people at PHP
> conferences and meetups c
On 4 November 2014 20:45, Brad Jorsch (Anomie) wrote:
> * People may store data in JSON blobs that must be parsed where a module
> using mw.loadData would be more appropriate.
> * People may write templates that attempt to bypass the normal MediaWiki
> parameter handling mechanism in favor of pas
On 9 November 2014 09:27, aude wrote:
> On Sun, Nov 9, 2014 at 8:51 AM, Pine W wrote:
>> I'm curious, Risker: if you don't mind my asking, what about being required
>> to supply a throwaway email address would have discouraged you from opening
>> a Wikimedia account?
> I understand that it can
On 16 November 2014 22:36, Pine W wrote:
> James: would it be possible to automatically save the text of a page to a
> user's sandbox when they encounter an edit conflict? This would overwrite
> the content of the sandbox, but that could be reverted using the normal
> history page for the sandbox
On 16 November 2014 22:58, Zack Weinberg wrote:
> On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk wrote:
>> It sounds like the data loss here was purely due to user error, David.
> Don't blame the victim.
+1. This is precisely the dataloss that needs to be averted.
>> Maybe we could allow saving
On 3 December 2014 at 17:03, Giuseppe Lavagetto
wrote:
> it's been quite a journey since we started working on HHVM, and last
> week (November 25th) HHVM was finally introduced to all users who didn't
> opt-in to the beta feature.
Excellent! Excellent! Does that make us the second-largest HHVM
On 3 December 2014 at 23:08, Ryan Kaldari wrote:
> Surely we can come up with a creative idea that is:
> * Easy for humans to solve
> * Can't be solved by out-of-the-box captcha breakers
> * Isn't trivial for programmers to solve
* isn't an abomination for accessibility
- d.
Is Zend PHP still tested also?
On 18 December 2014 at 17:11, Antoine Musso wrote:
> Hello,
>
> Jenkins runs the MediaWiki core unit tests under HHVM and the job will
> now prevent changes to be merged if it fails.
>
> Huge thanks to everyone that helped fix tests and HHVM code base!
>
> --
> Anto
On 19 December 2014 at 10:45, Quim Gil wrote:
> Andre won't tell you, but he wrote this:
> http://blogs.gnome.org/aklapper/2014/12/17/welcome-phabricator/
> The best in-depth analysis of a Bugzilla to Phabricator migration available
> in the Internet. Not that there is much competition... I'm sur
Yes.
1. penny-shavings for commits sets up terrible motivations.
2. these people are claiming money in developers' names without permission.
3. there's no evidence the whole thing isn't the scam it looks like.
On 9 January 2015 at 08:18, Tyler Romeo wrote:
> Link for those interested:
> http://p
I'd say: hit social media! Make MediaWiki and Wikimedia look like a
*happening place*.
Everyone [*] who runs PHP is looking seriously at HHVM right now, and
that's entirely because WMF moved to it.
The Phabricator migration made it to lwn.net, which is low-traffic but
high-quality.
Basically, co
On 16 January 2015 at 07:38, Chad wrote:
> These days I'm not convinced it's our job to support every possible
> scale of wiki install. There's several simpler and smaller wiki solutions
> for people who can't do more than FTP a few files to a folder.
In this case the problem is leaving users a
On 16 January 2015 at 16:09, Antoine Musso wrote:
> So what we might end up with:
> - Wikimedia using the SOA MediaWiki with split components maintained by
> staff and the Wikimedia volunteers devs. Code which is of no use for
> the cluster is dropped which would surely ease maintainability. We
On 16 January 2015 at 17:10, Greg Grossmeier wrote:
>
>> This is not a great idea because it makes WMF wikis unforkable in
>> practical terms. The data is worthless without being able to run an
>> instance of the software. This will functionally proprietise all WMF
>> wikis, whatever the licence
On 19 January 2015 at 01:46, Jay Ashworth wrote:
> Aha! Sorry; I was behind on Parsoid, was the problem. Yeah, if there's
> a way to edit in MWtext, both for humans and programs, then that serves the
> use cases I would be concerned about. Thanks for the prompt clarification,
> Daniel.
There
On 28 January 2015 at 08:13, Daniel Friesen wrote:
> We could also try convincing the semi-decent shared hosts like Dreamhost
> and Linode to run a service of their own for their customers.
Yes, reaching out to a shared hosting company or two is definitely
something to do at this stage!
Do Wo
Functionally. If you make a loud public declaration "WE SHALL NOT SUE"
then you sue, judges *tend* to look upon it very unfavourably. YMMV of
course.
On 4 February 2015 at 13:42, Nikolas Everett wrote:
> On Wed, Feb 4, 2015 at 5:09 AM, Yuri Astrakhan
> wrote:
>
>>
>>
>> For those not adicted to
On 7 February 2015 at 22:20, Tyler Romeo wrote:
> **However**, I’d like to take this opportunity and jump a step further. What
> would everybody think of switching to the AGPLv3 instead? The advantage that
> this provides, for those who don’t know, is a single additional restriction:
> when th
nto it, but what we have
> right now (link in the footer and extension information on Special:Version)
> should fulfill compliance automatically for third parties.
>
> --
> Tyler Romeo
> On Feb 7, 2015 6:00 PM, "David Gerard" wrote:
>
>> On 7 February 2015
On 7 February 2015 at 23:39, wctaiwan wrote:
> IANAL, but if there is some flexibility here, I would argue that extensions
> should *not* be considered derivatives. Legally, because extensions do not
> contain MediaWiki code (beyond using the programming API provided by core
> classes);
Ah, goo
On 8 February 2015 at 11:12, Max Semenik wrote:
> On Sun, Feb 8, 2015 at 2:13 AM, Tyler Romeo wrote:
>> (Also, we actually can’t switch to the MIT license without express
>> permissions from every developer who ever contributed to core anyway.)
> Same applies to AGPL.
I believe AGPL counts as
On 9 February 2015 at 04:51, Rob Lanphier wrote:
> Also, one cost of copyleft licenses is that they are much, much more
> complicated than permissive licenses. Even though many people feel
> comfortable with the compliance requirements of most OSI-approved
> licenses, the permissive licenses can
On 9 February 2015 at 08:28, Max Semenik wrote:
> OpenOffice's woes are unrelated to its license, it was already dead by
> forking when Oracle transferred it to Apache, facilitating a change from
> GPL+proprietary CLA to the Apache license.
Indeed, but they touted the mythical attractiveness o
On 10 February 2015 at 23:19, Bryan Tong Minh wrote:
> In fact I would prefer to go to a less restrictive license, but that is
> probably not worth the fight.
And is also infeasible. For a web service. GPL is effectively weak
copyleft already; I think that's quite weak enough. (As I noted, ther
Nice one!
Will anyone be porting all the Babel templates? That's a seriously
useful thing that should go there, and they aren't on Meta yet.
On 19 February 2015 at 01:06, Legoktm wrote:
> Hello!
>
> Global user pages have now been deployed to all public wikis for users with
> CentralAuth account
On 17 March 2015 at 02:55, Gergo Tisza wrote:
> On Mon, Mar 16, 2015 at 5:08 PM, Daniel Friesen
> wrote:
>> Bitcoin is not untraceable.
>> An adversary capable enough to eavesdrop on dissidents' communication
>> making them need Tor should be capable of tracing the publicly available
>> bitcoin
Looks like just a collaboration :-)
https://www.mediawiki.org/wiki/OpenStreetMap
https://meta.wikimedia.org/wiki/OpenStreetMap
https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia
Obviously we should be doing our own tile rendering and serving, for example.
On 18 March 2015 at 09:09
On 15 April 2015 at 09:38, Trevor Parscal wrote:
> I'm glad to hear VE had your back. This actually reminds me, there's a
> feature we never really advertised in VisualEditor where a CSV file can be
> dragged into the editor and a table is created from its contents.
We need a blog post about wh
Is there a facility to use this in VE?
On 6 May 2015 at 12:25, Jon Robson wrote:
> I think this is great but I'm still super super concerned about the support
> for "Embedded directly with ". I'm concerned as if used this way we
> risk making wikitext even more like code and more difficult for ot
On 19 September 2012 09:20, aude wrote:
> If anything, I think in the download button / dialog in Commons, we should
> have an option to allow user to choose image of any size to download, in
> addition to the preset choices. :)The thumbnails can be temporary I
> suppose, and hope no one uses
On 19 September 2012 09:25, David Gerard wrote:
> The Commons reuse guide [1] notes that hotlinking thumbnails is
> allowed, but it's a terrible idea and you should either store the
> image locally or use InstantCommons (which works wonderfully).
[1]
https://commons.wiki
On 28 September 2012 02:47, Mark A. Hershberger wrote:
> The problem, though, is that there is no way to install, use, or update
> extensions apart from doing it by hand. Requiring the installation of
> multiple modules by hand isn't going to lead to a thriving, modular
> ecosystem. We need a d
I made it up at work a few weeks ago :-) We were discussing the
questionable maintainability of apps and languages that insist on
handrolling their own dependency management, particularly when they do
it in a way that doesn't match how distros do it.
On 28 September 2012 15:23, Derric Atzrott wro
On 28 September 2012 15:25, Derric Atzrott wrote:
>>Where is that quote from? It is so incredibly true.
> Sorry all. I meant to send that to just him.
And then I failed to notice I was sending to the list too.
apt-get purge clue
- d.
___
Wikitec
On 28 September 2012 17:01, Mark A. Hershberger wrote:
> I do agree with David Gerard's assessment, though. We need to make sure
> that whatever we use is going to work with package management tools that
> Debian and Redhat and the like already use.
The other reason is, of course, making the d
On 17 October 2012 09:02, Platonides wrote:
> Note however that there are some pictures with multiple authors
> (derivative works, collages...) and those are harder to determine and
> store (a simple field for the author is not enough).
And some images would need a credit *trail*. And specified
On 17 October 2012 09:15, Emmanuel Engelhart wrote:
> Le 17/10/2012 10:07, David Gerard a écrit :
>> And some images would need a credit *trail*. And specified credit for
>> some CC images gets wacky too.
> I do not think we need to cite all the authors (could be indeed
On 24 October 2012 19:08, Peter Youngmeister wrote:
> As of this moment, all imagescalers are now running ubuntu 12.04
> precise pangolin. This should close a number of bugzilla tickets, as
> well as remove the final blocker for timed media handler.
\o/
You know, I was just going to ask again
https://bugzilla.wikimedia.org/show_bug.cgi?id=38799
Is there anyone who can look into this? It was raised on wikimediauk-l again.
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 25 November 2012 21:36, Raylton P. Sousa wrote:
> I keep thinking that (particularly) the wikivoyage[1] could be much
> better if we had good maps similar to the dantonwiki[2] (that runs on
> localwiki[3]).
> Is there any similar map project in mediawiki that can be activated in
> small wikivo
On 27 November 2012 16:39, Andre Klapper wrote:
> I propose adding a *new* priority called "Immediate" which should only
> be used to mark really urgent stuff to fix. This priority would be added
> above the existing "Highest" priority.
Has anyone suggested a separate "urgency" parameter?
- d
On 27 November 2012 17:09, Andre Klapper wrote:
> 2) Look at our priority definitions in
> https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority
> a) "normal" means "Should be fixed by the next release."[1]
> This is extremely unrealistic with above usage of "Normal".
You may be up against h
On 27 November 2012 21:58, rexx wrote:
> The ability to turn this on or off for your browser is unfortunately hidden
> away in a tab in the 'Filter preferences ...' of ABP. There's also an
> individual whitelist there. It's probably worth reading the developer's blog
> at http://adblockplus.org/b
1 - 100 of 756 matches
Mail list logo