This schedule is excellent news.
I am working on integrating Moodle with mediawiki and having a Sul support
would be great.
we are looking at two basic use cases.
1. Allowing existing user to log into Moodle via openid.
2. Making edits such as clearing the sandbox on behalf of students.
Hey,
Because of this, I can be fairly confident in recommending thata my
team avoids the use of TDD.
Clearly you are not a fan of TDD. Which is entirely fine. If you adopt this
practice or not is a personal choice, and not one that should be forced
upon anyone. Like with all practices,
On Sat, Jun 1, 2013 at 12:14 AM, Ori Livneh o...@wikimedia.org wrote:
This
amounts to a workaround for git-review's tendency to frighten you into
thinking you're about to submit more patches than the ones you are working
on.
Thanks Ori, I have tested it with a couple of repositories and it
As the dumb ass trying to merge a lot of the code last year at
Wikidata I would say stop bitching about whether to make tests or not.
Any tests are better than no tests, without tests merging code is pure
gambling. Yes you can create a small piece of code and be fairly sure
that your own code
Hello,
Since we introduced hooks in MediaWiki, the documentation has been
maintained in a flat file /docs/hooks.txt . Over the week-end I have
converted the content of that file to let Doxygen recognize it.
The patchset is:
https://gerrit.wikimedia.org/r/#/c/66128/
I have used that patch to
On 06/04/2013 11:37 AM, John Erling Blad wrote:
It is like writing a
document with no spell checker vs using a spell checker.
Which would be the right moment to remind you of the Cupertino effect
that illustrates so well how the combination of automation and trust in
that automation is known to
Hey,
My own experience is that test coverage is a poor evaluation metric
for anything but test coverage; it doesn't produce better code, and
tends to produce code that is considerably harder to understand
conceptually because it has been over-factorized into simple bits that
hide the actual
Looks pretty nice. My only complaint is that on the list page the hook
header text is the same font size and weight as the Parameters header. I
know it's indented, so you can sort of tell, but for ease of use purposes I
think we should somehow change that.
- The hooks are documented in a
On Tue, Jun 4, 2013 at 12:36 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
Hey,
My own experience is that test coverage is a poor evaluation metric
for anything but test coverage; it doesn't produce better code, and
tends to produce code that is considerably harder to understand
Test coverage is not a quality metric, it is a quantity metric. That
is it says something about the amount of tests. The coverage can say
something about the overall code given that the code under test infact
reflect the remaining code. As the code under test usually are better
than the remaining
On 06/04/2013 12:57 PM, Nikolas Everett wrote:
The thing is quite a few of us have seen cases where people bend over
backwards for test coverage, sacrificing code quality and writing tests
that don't provide any real value.
Probably better expressed than I did.
My point is: clearly test
On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso hashar+...@free.fr wrote:
Since we introduced hooks in MediaWiki, the documentation has been
maintained in a flat file /docs/hooks.txt . Over the week-end I have
converted the content of that file to let Doxygen recognize it.
The patchset is:
On Tue, Jun 4, 2013 at 1:40 PM, Brad Jorsch bjor...@wikimedia.org wrote:
On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso hashar+...@free.fr wrote:
Since we introduced hooks in MediaWiki, the documentation has been
maintained in a flat file /docs/hooks.txt . Over the week-end I have
converted
On Tue, Jun 4, 2013 at 1:43 PM, Chad innocentkil...@gmail.com wrote:
On Tue, Jun 4, 2013 at 1:40 PM, Brad Jorsch bjor...@wikimedia.org wrote:
On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso hashar+...@free.fr
wrote:
Since we introduced hooks in MediaWiki, the documentation has been
Le 04/06/13 20:03, Ryan Lane a écrit :
I've never understood why we have some subsection of documentation stuck in
the tree. It makes no sense. If we want to include docs with the software
shouldn't we just dump tagged docs from mediawiki.org into the tree, per
release? Right now we have
On 4 June 2013 19:00, Antoine Musso hashar+...@free.fr wrote:
Hello,
Thoughts ?
I had taken another approach in Translate which was designed to be
easy to sync to wiki:
*
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FTranslate.git/2cd676fd53e4d2dd45ac22972175739f0b3e2bf0/hooks.txt
*
On 06/04/2013 07:42 AM, oren bochman wrote:
This schedule is excellent news.
I am working on integrating Moodle with mediawiki and having a Sul support
would be great.
we are looking at two basic use cases.
1. Allowing existing user to log into Moodle via openid.
2. Making edits such
On 06/04/2013 02:03 PM, Ryan Lane wrote:
I've never understood why we have some subsection of documentation stuck in
the tree. It makes no sense. If we want to include docs with the software
shouldn't we just dump tagged docs from mediawiki.org into the tree, per
release? Right now we have
Can you give any examples of real code that become less clear after it
was rewritten for testability, and explain why it is worse after the
rewrite?
On Tue, Jun 4, 2013 at 7:20 PM, Marc A. Pelletier m...@uberbox.org wrote:
On 06/04/2013 12:57 PM, Nikolas Everett wrote:
The thing is quite a few
On Tue, Jun 4, 2013 at 3:38 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote:
See
https://www.mediawiki.org/wiki/OAuth#Suggested_Granularity_of_Permissions(list
is not final).
Who wrote this? Some interesting excerpts:
- Third party app's code *must* be free software or at least open
On 04/06/13 22:29, Jeroen De Dauw wrote:
Hey,
Because of this, I can be fairly confident in recommending thata my
team avoids the use of TDD.
Clearly you are not a fan of TDD. Which is entirely fine. If you adopt this
practice or not is a personal choice, and not one that should be
On 06/04/2013 06:13 PM, Tyler Romeo wrote:
- Third party app's code *must* be free software or at least open
source (up for debate)
In other words, if you want to make a closed source Wikipedia app, it has
to be insecure.
Could you clarify this? I haven't been following this debate
On Tue, Jun 4, 2013 at 7:11 PM, Mark A. Hershberger m...@everybody.orgwrote:
Could you clarify this? I haven't been following this debate closely
(real life has intervened) but this seems strange to me.
Of course, we can't control the license anyone puts on their code, but
saying that if
On 05/06/13 01:17, Tyler Romeo wrote:
By saying you can only use OAuth if you're open source, it's the same as
saying if you're closed source you must use insecure authentication
methods. Because just saying OAuth must be open source isn't going to stop
closed source developers.
Yes, of
On Tue, Jun 4, 2013 at 7:31 PM, Platonides platoni...@gmail.com wrote:
Yes, of course. It makes no sense. I changed it to a _should_ in the wiki
page
Thanks. I figure it was just written quickly during brainstorming.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in
On Tue, Jun 4, 2013 at 4:31 PM, Platonides platoni...@gmail.com wrote:
On 05/06/13 01:17, Tyler Romeo wrote:
By saying you can only use OAuth if you're open source, it's the same as
saying if you're closed source you must use insecure authentication
methods. Because just saying OAuth must be
On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier ro...@wikimedia.org wrote:
This page is more relevant to our immediate plans:
https://www.mediawiki.org/wiki/Auth_systems/OAuth
I would be really happy to see someone do some cleanup of this page,
archive the bits written in 2011, and make the
On Tue, Jun 4, 2013 at 4:56 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier ro...@wikimedia.org wrote:
This page is more relevant to our immediate plans:
https://www.mediawiki.org/wiki/Auth_systems/OAuth
I would be really happy to see someone do some
On Tue, Jun 4, 2013 at 8:35 PM, Chris Steipp cste...@wikimedia.org wrote:
We initially were going to use your patch and limit based on module,
but there were a few places where that seemed too course. But then if
we just used user rights, then to edit a page the user needed to grant
8 (iirc)
On 05/06/13 02:37, Tyler Romeo wrote:
On Tue, Jun 4, 2013 at 8:35 PM, Chris Steippcste...@wikimedia.org wrote:
We initially were going to use your patch and limit based on module,
but there were a few places where that seemed too course. But then if
we just used user rights, then to edit a
On Tue, 04 Jun 2013 17:35:24 -0700, Chris Steipp cste...@wikimedia.org
wrote:
The biggest issue we hit with the permissions was trying to balance
fine granularity and not overwhelming the user with the list of what
was being requested and have them blindly agree to it.
We initially were
On Tue, Jun 4, 2013 at 7:56 PM, Tyler Romeo tylerro...@gmail.com wrote:
Why?! What exactly is so bad about just using our own permissions, which
already exists, as the permissions for OAuth tokens. It allows the highest
level of granularity for permissions and allows us to easily display to the
On 06/04/2013 06:13 PM, Tyler Romeo wrote:
- Rollback of all the actions by an individual application should be
possible.
Yeah, if they mean a single rollback FooApp button, that's probably
not going to happen.
Matt Flaschen
___
Wikitech-l
On Tue, Jun 4, 2013 at 9:50 PM, Brad Jorsch bjor...@wikimedia.org wrote:
No, it doesn't. You think we didn't discuss this already?
I'm sure you did, but it's kind of useless if nobody provides an
explanation. Do you really expect me to just accept that some WMF
engineers somewhere decided it
On 06/04/2013 09:48 PM, Daniel Friesen wrote:
Next autoconfirmed. This one you might just filter out to. Does anyone
know of any situation you'd expect OAuth to let an app Edit any page I
can edit, but not the semi-protected ones I could usually edit.?
edit, createpage, and createtalk can
Hi,
I'm retaking the work I started a couple of weeks ago in the Amsterdam
Hackathon about improving code coverage of the Upload code. At the
moment my main question is how to test all the code paths dealing with
files not written to the FS because of permissions, missing dirs, etc.
Is there a
36 matches
Mail list logo
