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 rec
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
On Tue, Jun 4, 2013 at 9:50 PM, Brad Jorsch 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 was best"?
If you go
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-
On Tue, Jun 4, 2013 at 7:56 PM, Tyler Romeo 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
> user exactly wh
On Tue, 04 Jun 2013 17:35:24 -0700, Chris Steipp
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 going to use your patch an
On 05/06/13 02:37, Tyler Romeo wrote:
On Tue, Jun 4, 2013 at 8:35 PM, Chris Steipp 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
On Tue, Jun 4, 2013 at 8:35 PM, Chris Steipp 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) permissions.
>
Ma
On Tue, Jun 4, 2013 at 4:56 PM, Tyler Romeo wrote:
> On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier 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,
>> archi
On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier 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 Auth_systems/OAuth
On Tue, Jun 4, 2013 at 4:31 PM, Platonides 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 open source
On Tue, Jun 4, 2013 at 7:31 PM, Platonides 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 Computer Science
w
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 cou
On Tue, Jun 4, 2013 at 7:11 PM, Mark A. Hershberger wrote:
> 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 they produce sof
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 deb
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
On Tue, Jun 4, 2013 at 3:38 PM, Matthew Flaschen wrote:
> 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
>source (up f
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 wrote:
> On 06/04/2013 12:57 PM, Nikolas Everett wrote:
>> The thing is quite a few of us have see
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
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 edi
On 4 June 2013 19:00, Antoine Musso 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
* https://www.media
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 ha
On Tue, Jun 4, 2013 at 1:43 PM, Chad wrote:
> On Tue, Jun 4, 2013 at 1:40 PM, Brad Jorsch wrote:
> > On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso
> wrote:
> >>
> >> Since we introduced hooks in MediaWiki, the documentation has been
> >> maintained in a flat file /docs/hooks.txt . Over the wee
On Tue, Jun 4, 2013 at 1:40 PM, Brad Jorsch wrote:
> On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso 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
On Tue, Jun 4, 2013 at 12:00 PM, Antoine Musso 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:
> https://ger
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 cov
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 c
On Tue, Jun 4, 2013 at 12:36 PM, Jeroen De Dauw wrote:
> 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 bec
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 separa
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 a
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 t
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 ge
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 works
On Sat, Jun 1, 2013 at 12:14 AM, Ori Livneh 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 works
great. N
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, effect
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.
Unfo
36 matches
Mail list logo
