On Wed, Aug 12, 2009 at 2:38 AM, Chad wrote:
>
> My point is that not declaring visibility on new code (ie: leaving
> everything public) is poor form. It usually doesn't take very long to
> make the decision about what scope to put a function or variable
> in, and it can always be changed later if
On 12/08/2009, at 1:16 AM, Chad wrote:
> On the whole "new code" front. Can we all /please/ remember that
> we're writing PHP5 here. Visibility on all new functions and variables
> should also be a must.
I honestly don't think this is that important. We should err on the
side of public, not pri
On Wed, Aug 12, 2009 at 8:31 AM, Andrew Garrett wrote:
>
> On 12/08/2009, at 1:16 AM, Chad wrote:
>> On the whole "new code" front. Can we all /please/ remember that
>> we're writing PHP5 here. Visibility on all new functions and variables
>> should also be a must.
>
> I honestly don't think this i
Aryeh Gregor wrote:
> Or whatever. We have *way* too few high-level comments in our code.
> We have entire files -- added quite recently, mind you, by established
> developers -- that have no or almost no documentation on either the
> class or function level. We can really do better than this! I
On Wed, Aug 12, 2009 at 8:31 AM, Andrew Garrett wrote:
> I honestly don't think this is that important. We should err on the
> side of public, not private or protected.
>
> Very frequently, I've had to change visibility on functions because
> somebody hasn't anticipated a case where a class functio
Do you know how are ordered the users who edited a page in the enhanced
recentchanges feature? See
http://meta.wikimedia.org/w/index.php?title=Help%3AEnhanced_recent_changes&diff=1570240&oldid=1476276
I can't understand if there's a logical order or there's a bug.
Thanks,
Nemo
___
I'm starting a new thread because I noticed my news reader has glued together
messages with the title "A potential land mine" and "MW test infrastructure
architecture," which may confuse someone coming into the discussion late. Also,
the previous thread has branched into several topics and I wan
On Wed, Aug 12, 2009 at 10:59 AM, dan nessett wrote:
> I'm starting a new thread because I noticed my news reader has glued together
> messages with the title "A potential land mine" and "MW test infrastructure
> architecture," which may confuse someone coming into the discussion late.
> Also, t
--- On Wed, 8/12/09, Chad wrote:
>
> Tests should run in a vanilla install, with minimal
> dependency on
> external stuff. PHPUnit
> (or whatever framework we use) would be considered an
> acceptable dependency for
> test suites. If PHPUnit isn't available (ie: already
> installed and in
> the i
Hi!
When we go to links such as:
http://pt.wikibooks.org/w/index.php?action=edit&preload=Project:About&title=test
http://pt.wikibooks.org/w/index.php?action=edit&preload=Project:About&title=MediaWiki:test
we note that both "test"and "MediaWiki:test" doesn't exist. But using the
preload parameter f
I have been playing around with phpunit, in particular its facility for
generating tests from existing PHP code. You do this by processing a suitably
annotated (using /* @assert ... */ comment lines) version of the file with
phpunit --skeleton. Unfortunately, the --skeleton option assumes the fi
On 8/12/09 7:59 AM, dan nessett wrote:
[snip]
> For example, people shot down my proposal to automatically
> discover the MW root directory because some production systems have
> administrators without root access, without the ability to load code
> into the PEAR directory, etc.
[snip]
We *already
--- On Wed, 8/12/09, Brion Vibber wrote:
> We *already* automatically discover the MW root directory.
Yes, you're right. I should have said automatically discover the MW root
directory without using file position dependent code.
Dan
___
Wik
On 8/12/09 9:51 AM, dan nessett wrote:
> --- On Wed, 8/12/09, Brion Vibber wrote:
>
>> We *already* automatically discover the MW root directory.
>
> Yes, you're right. I should have said automatically discover the MW
> root directory without using file position dependent code.
The suggestions we
--- On Wed, 8/12/09, Brion Vibber wrote:
>
> The suggestions were for explicit manual configuration, not
>
> autodiscovery. Autodiscovery means *not* having to set
> anything. :)
I am insane to keep this going, but the proposal I made did not require doing
anything manually (other than runnin
2009/8/12 dan nessett :
> I am insane to keep this going, but the proposal I made did not require doing
> anything manually (other than running the install script, which you have to
> do anyway). The install script knows (or can find out) where the MW root is
> located. It could then either: 1)
--- On Wed, 8/12/09, Roan Kattouw wrote:
> On shared hosting, both are impossible. MediaWiki currently
> works with
> minimal write access requirements (only the config/
> directory for the
> installer and the images/ directory if you want uploads),
> and we'd
> like to keep it that way for peopl
> "dn" == dan nessett writes:
dn> suggest breaking LocalSettings into two parts
I've always wanted a public part, say linked from Special:Version, "view
public initialization settings", with a standard URL,
title=Special:PublicLocalSettings perhaps, and all without needing to
install an exten
On Wed, Aug 12, 2009 at 1:42 PM, wrote:
>> "dn" == dan nessett writes:
> dn> suggest breaking LocalSettings into two parts
>
> I've always wanted a public part, say linked from Special:Version, "view
> public initialization settings", with a standard URL,
> title=Special:PublicLocalSettings p
Are there any license requirements for extensions checked into wikimedia's
SVN? I am taking over maintanance of an OpenSSO authentication extension
from Sun, and it is currently CDDL licensed.
Does it need to be GPL, or is CDDL an acceptable license?
V/r,
Ryan Lane
__
On 8/12/09 11:19 AM, Lane, Ryan wrote:
> Are there any license requirements for extensions checked into wikimedia's
> SVN? I am taking over maintanance of an OpenSSO authentication extension
> from Sun, and it is currently CDDL licensed.
>
> Does it need to be GPL, or is CDDL an acceptable license?
2009/8/12 :
> often, and link to that. I.e., _you are not making being open source easy_.
>
This has absolutely nothing to do with MediaWiki being open source or
not. It's not like there's closed-source wikis out there of equivalent
quality that don't have this nuisance.
On topic: I agree with Ch
> Well, as I understand CDDL isn't compatible with GPL. so if you're
> pulling it into MediaWiki at runtime you enter the GPL
> Mystery Zone(TM)
> where things may, or may not, be properly licensed. :)
>
> But I wouldn't object to CDDL code being in the repository,
> as long as
> we're not mi
> "RK" == Roan Kattouw writes:
RK> 2009/8/12 :
>> often, and link to that. I.e., _you are not making being open source easy_...
RK> This has absolutely nothing to do with MediaWiki being open source
...for hook authors.
___
Wikitech-l mailing list
I am investigating how to write a comprehensive parser regression test. What I
mean by this is something you wouldn't normally run frequently, but rather
something that we could use to get past the "known to fail" tests now disabled.
The problem is no one understands the parser well enough to ha
--- On Wed, 8/12/09, dan nessett wrote:
> "If you ran this test on, for example, Wikipedia,
Of course, what I meant is run the test on the Wikipedia database, not on the
live system.
Dan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimed
2009/8/12 dan nessett :
> I am investigating how to write a comprehensive parser regression test. What
> I mean by this is something you wouldn't normally run frequently, but rather
> something that we could use to get past the "known to fail" tests now
> disabled. The problem is no one understa
So. I checked out a copy of phase3 and extensions to start working on
investigating the feasibility of a comprehensive parser regression test. After
getting the working copy downloaded, I do what I usually do - blow away the
extensions directory stub that comes with phase3 and soft link the down
On Wed, Aug 12, 2009 at 4:39 PM, dan nessett wrote:
> So. I checked out a copy of phase3 and extensions to start working on
> investigating the feasibility of a comprehensive parser regression test.
> After getting the working copy downloaded, I do what I usually do - blow away
> the extensions
--- On Wed, 8/12/09, Roan Kattouw wrote:
> I read this paragraph first, then read the paragraph above
> and
> couldn't help saying "WHAT?!?". Using a huge set of pages
> is a poor
> replacement for decent tests.
I am not proposing that the CPRT be a substitute for "decent tests." We still
need
Chad wrote:
> DumpHTML will not be moved back to maintenance in the repo, it was
> already removed from maintenance and made into an extension. Issues
> with it as an extension should be fixed, but it should not be encouraged
> to go back into core.
What I meant was I can move the code in DumpH
On 8/12/09 1:39 PM, dan nessett wrote:
> This works on a deployed version of MW, since the extensions
> directory is embedded in /phase3. But, in a development version,
> where /extensions is a separate subdirectory
Your setup is incorrect: the extensions folder *always* goes inside the
MediaWiki
On Wed, Aug 12, 2009 at 4:48 PM, dan nessett wrote:
> --- On Wed, 8/12/09, Roan Kattouw wrote:
>
>> I read this paragraph first, then read the paragraph above
>> and
>> couldn't help saying "WHAT?!?". Using a huge set of pages
>> is a poor
>> replacement for decent tests.
>
> I am not proposing th
--- On Wed, 8/12/09, Brion Vibber wrote:
> Your setup is incorrect: the extensions folder *always*
> goes inside the
> MediaWiki root dir. Always.
>
Sorry, my inexperience with Subversion led me in the wrong direction. I didn't
realize I could check out phase3 then point Subversion to the ext
On Wed, Aug 12, 2009 at 6:04 PM, dan nessett wrote:
> --- On Wed, 8/12/09, Brion Vibber wrote:
>
>> Your setup is incorrect: the extensions folder *always*
>> goes inside the
>> MediaWiki root dir. Always.
>>
>
> Sorry, my inexperience with Subversion led me in the wrong direction. I
> didn't rea
dan nessett wrote:
> I am investigating how to write a comprehensive parser regression test. What
> I mean by this is something you wouldn't normally run frequently, but rather
> something that we could use to get past the "known to fail" tests now
> disabled. The problem is no one understands
dan nessett wrote:
> --- On Wed, 8/12/09, Brion Vibber wrote:
>
>
>> Your setup is incorrect: the extensions folder *always*
>> goes inside the
>> MediaWiki root dir. Always.
>>
>>
>
> Sorry, my inexperience with Subversion led me in the wrong direction. I
> didn't realize I could check
Chad wrote:
> [...]
> What we need is something similar to parser tests, where it's
> absurdly easy to pop new tests in with little to no coding
> required at all. [...]
Is it really so much more difficult to write
| TestAddArticle ("Main Page", "blah blah");
than
| !! article
| Main Page
| !
On Wed, Aug 12, 2009 at 6:40 PM, Tim Landscheidt wrote:
> Chad wrote:
>
>> [...]
>> What we need is something similar to parser tests, where it's
>> absurdly easy to pop new tests in with little to no coding
>> required at all. [...]
>
> Is it really so much more difficult to write
>
> | TestAddAr
Brion Vibber wrote:
> [...]
>> I'm primarily thinking about the certificates for:
>> - wikitech.leuksman.com
> This is an old link from when we stuck our tech doc wiki on my personal
> site for a while; you'll see there's a nicer cert at the permanent URL:
> https://wikitech.wikimedia.org/
> [.
Daniel Kinzler wrote:
>>> - www.wikimedia.de
>> Wikimedia DE folks run this... Who can poke it?
> I can. We have a cert for https://secure.wikimedia.de/ which we use for
> donations and stuff. what do we need one for www.wikimedia.de for?
Well, www.wikimedia.de answers on port 443, so a valid
Brion Vibber wrote:
>> Here's what I do in similar circumstances. Create another variable,
>> $wgScriptPathEscaped. Then, gradually make the changes. Wait for tests.
>> Change some more. Eventually, most of the old ones will be gone.
> $wgScriptPath is a URL fragment, and by definition MUST
2009/8/12 Chad :
> To elaborate on the final point. Sometimes the parser is changed and
> it breaks output on purpose. Case in point was when Tim rewrote the
> preprocessor. Some parts of syntax were intentionally changed. You'd
> have to establish a new baseline for this new behavior at that point
--- On Wed, 8/12/09, Tim Landscheidt wrote:
> I think though that more people
> would read and embrace your
> thoughts if you would find
> a more concise way to put
> them across :-).
Mea Culpa. I'll shut up for a while.
___
Wikitech-l maili
On 8/12/09 3:49 PM, Tim Landscheidt wrote:
> Brion Vibber wrote:
>
>> [...]
>>> I'm primarily thinking about the certificates for:
>
>>> - wikitech.leuksman.com
>
>> This is an old link from when we stuck our tech doc wiki on my personal
>> site for a while; you'll see there's a nicer cert at the
On 8/12/09 2:55 PM, Chad wrote:
> To elaborate on the final point. Sometimes the parser is changed and
> it breaks output on purpose. Case in point was when Tim rewrote the
> preprocessor. Some parts of syntax were intentionally changed. You'd
> have to establish a new baseline for this new behavio
Unsecure Sockets Layer?
(I'll shut up now 8-)
On Wed, Aug 12, 2009 at 4:12 PM, Brion Vibber wrote:
> On 8/12/09 3:49 PM, Tim Landscheidt wrote:
>> Brion Vibber wrote:
>>
>>> [...]
I'm primarily thinking about the certificates for:
>>
- wikitech.leuksman.com
>>
>>> This is an old link f
On 8/12/09 4:05 PM, Roan Kattouw wrote:
> Exactly. Instead of throwing a huge amount of wikitext at it and
> hoping that'll cover everything, we should make our test suite more
> comprehensive by adding lots of new parser test. Of course there'll be
> *some* crazy bugs concerning weird interactions
Helder Geovane kindly asked me to post this here, after I published a comment at
http://meta.wikimedia.org/wiki/Talk:SVG_image_support#Batik_server_revisited
This started out when a colleague posted a proposal on strategy wiki of throwing
some foundation money at the active development of rsvg. I
On Wed, Aug 12, 2009 at 10:59 AM, dan nessett wrote:
> If a developer has more system privileges than a production admin, to what
> extent? Can we assume he has root access? If not, can we assume he can get
> someone who has to do things like install PHPUnit? Can we assume the
> availability of
On Wed, Aug 12, 2009 at 7:19 PM, hk_kng wrote:
> Helder Geovane kindly asked me to post this here, after I published a comment
> at
> http://meta.wikimedia.org/wiki/Talk:SVG_image_support#Batik_server_revisited
>
> This started out when a colleague posted a proposal on strategy wiki of
> throwing
On Wed, Aug 12, 2009 at 5:03 PM, Brion Vibber wrote:
> Your setup is incorrect: the extensions folder *always* goes inside the
> MediaWiki root dir. Always.
I don't do this on my development wiki. I use a checkout of trunk, so
extensions/ is inside phase3/../. Are there any significant problems
52 matches
Mail list logo
