On Thu, Sep 1, 2011 at 12:56 AM, Brion Vibber wrote:
> Note that this should get fixed once all the sites are running on https,
> since we can bump all the cookie-setters onto the current protocol. In the
> meantime, do consider https://commons.wikimedia.org/ to be very
> experimental!
>
Depending
On Sun, Aug 28, 2011 at 2:55 AM, Sumana Harihareswara
wrote:
> I'd like an accurate, visually pleasing way to count how many unreviewed
> revisions there are in trunk, for when I'm encouraging volunteer code
> review. TL;DR version: it would be great if someone fixed up RobLa's
> chart, corrected
On Thu, Aug 25, 2011 at 8:29 PM, Mark A. Hershberger
wrote:
> https://bugzilla.wikimedia.org/29246 -- API errors occasionally with
> unknown error 231
>
That one has kind of had my name on it for a while. I've assigned it
to myself and will tackle it either tonight or tomorrow morning.
> https
On Tue, Aug 23, 2011 at 9:51 AM, Alex Bernier wrote:
> Hello,
>
> I would like to remove the checkbox which allow logged users to mark changes
> as 'minor' when editing a page. Is it possible ? I use MediaWiki 1.17.
$wgGroupPermissions['user']['minoredit&
I've been doing some code review today, and updated the revision
report at
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/MediaWiki_roadmap/1.18/Revision_report
. The number of new revs in 1.18 dropped to 92 today, the first time
it's below 100. Yay!
A side effect of reviewing code, though
unt can do analysis on the data as it comes in, which
is a good thing cause it means less work for me :)
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Aug 16, 2011 at 12:52 PM, Bryan Tong Minh
wrote:
> You should put Special:PasswordReset in $wgWhiteListSomething.
>
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Manual:$wgWhitelistRead
Roan Kattouw (Catrope)
___
Wikitech-l m
is a little bit
higher-traffic than hewiki) and we were fine. We just didn't do much
with the data at the time IIRC (apart from looking at 'how many times
was each link clicked for the duration of the tracking', which only
tells you which
On Tue, Aug 16, 2011 at 1:26 AM, wrote:
> Unknown property 'zoom'. Declaration dropped. @
> http://transgender-taiwan.org/load.php?debug=false&lang=zh-tw&modules=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.special%7Cskins.vector&only=styles&skin=vector&*:1
> Expected declaration but found
On Mon, Aug 15, 2011 at 11:48 PM, Amir E. Aharoni
wrote:
> In the Hebrew Wikipedia there's been some discussions about changing
> the links in the sidebar. Is there a clever way to do it by using
> click statistics?
>
> For example, can we get statistics about how many people click each
> link in
I second this notion, meeting up with local Wikimedians in some way,
maybe even inviting them to hang around the venue even if they're not
coders, sounds like a great idea.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@
rceLoader
> feature.
>
Yes, you will have broken CSS precendence order for site/user CSS.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Jul 14, 2011 at 8:55 PM, Ryan Lane wrote:
> Over the past couple days Roan Kattouw and I have been pushing out
> changes to enable protocol-relative URL support. We've gotten to a
> point where we think it is stable and working.
>
> We've enabled this on test.w
On Thu, Aug 4, 2011 at 2:13 AM, Peter Youngmeister wrote:
> Hey,
>
> I looked at this a little while ago for a previous job. I think that
> it's a pretty awesome idea, but sadly I could never even find source
> for their research, much less any reports of it being successfully
> deployed in the wi
On Wed, Aug 3, 2011 at 8:47 AM, Brion Vibber wrote:
> Sounds good -- can we get a firm commitment that this is our schedule?
I think RobLa wants the reverse: a firm commitment from *us* that this
is our schedule. It looks good to me too.
Roan
___
Wikit
On Wed, Aug 3, 2011 at 2:54 AM, Rob Lanphier wrote:
> * 482 revs for code review. September 16 completion?
Given your data-based approach, that sounds good to me. Also consider
that het deploy will be 'done' at some point and Aaron will have more
time to spend on review. Besides that, I will hav
erwise
something is very wrong. I wouldn't know how to debug this without
more information. Is the JavaScript console reporting any JS errors?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Jul 30, 2011 at 6:16 PM, Daniel Kinzler wrote:
> Hi all!
>
> Ask you may know, there will be an "Ask the Developers" panel at Wikimania.
> However, there are no developers to ask, yet :) To make this work, we need a
> few lead WMF developers on the stage, ready to answer questions. So ple
se before sending
the SQL to the DB backend, so make sure you test your queries with
these substitutions applied
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jul 18, 2011 at 9:29 PM, Rob Lanphier wrote:
> Chad Horohoe (^demon on IRC) is going to be the one rebranching.
>
Rebranching is now done, see
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/92475
and friends. I'm about to take a few things out.
Roan
ady have a set of parsers that work with special:export data
> so I'm inclined to go with that.
>
You can use api.php?action=query&export&exportnowrap&titles=Foo|Bar|Baz
, that should give you the same format.
Roan Kattouw (Catrope)
__
On Thu, Jul 7, 2011 at 10:02 PM, David Gerard wrote:
> Are we talking about WMF deployments or tarballs here? Speaking as a
> tarball user, 2 releases a year, maybe 3, is *just fine*.
>
I think 3 releases per year is fine. However, I think we should deploy
to WMF sites much more often than that. T
>>> $.fn.jquery
"1.4.2"
> Also, it was easier for me
> to deploy this fix for UW because all its ajax calls go through an API
> object.
>
> In jQuery 1.4 you can fix this in a more standardized way, with ajax
> filters.
>
Well as I just pointed out, we have
r due to lack of reliable
internet access, or lack of sleep) until Thursday morning PDT.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
C 6.0; InfoPath.2; .NET4.0C)
>
> Are there any other reasons why someone would be rejected from the API?
Ah yes, the IE6 detection code just looks for "MSIE" in the User-Agent header :D
This'll all be fixed when I deploy the new code for dealing with the
IE6 issue. I will proba
On Sun, Jul 3, 2011 at 3:21 AM, Ryan Kaldari wrote:
> Instead of getting a result from the API, he gets a 403 error: "The
> website declined to show this webpage / HTTP 403"
>
Is he using IE6? I think we still haven't deployed the proper fixes
for the IE6 extension issue yet, although they did go
ll result in almost 20 edits per minute, that's way too much.
If you're operating a bot, you should get an account for it and ask
for a bot flag. That way you'll be exempt from rate limits and the
bot's edits will be hidden from Special:RecentChanges if you pass
&bot=1 i
change from page to
page) or the ResourceLoaderGetConfigVars hook (for config variables
that don't change from page to page).
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
side of the country a month later?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Jun 30, 2011 at 1:15 AM, Mark A. Hershberger
wrote:
> Roan suggested that the page may have been deleted and undeleted, thus
> removing the edit protection.
Credit where credit is due: this was Platonides.
Roan Kattouw (Catrope)
___
Wiki
On Thu, Jun 30, 2011 at 12:07 AM, Brion Vibber wrote:
> Do you have any custom
> settings, JS or gadgets set up that might change editing behavior?
More specifically, do you have WikiEditor enabled? If so, disable all
of the WikiEditor features/modules (see $wgWikiEditorModules or
$wgWikiEditorFea
On Wed, Jun 29, 2011 at 3:03 AM, Mark A. Hershberger
wrote:
> Although r47450 is from February 18, 2009, so I'm not sure what the deal
> is there.
>
I think r47450 is RobLa's cut-off point for "before this point,
revisions being mass-set to old/ok screw up the stats".
Roan
__
're probably not running through wfExpandURL.
>
Good point, but I'm more worried about the reverse TBH: what if
there's some code that runs stuff through wfExpandUrl() even though it
could, and maybe even should, be protocol-relative?
Roan Kattouw (Catrope)
__
.wikimedia.org/site/lang/etc) or where our static assets
and RL things are served from (bits), especially if broken URLs get
cached in Squid and/or memcached. This is why we're scheduling this
thing this far out when Ryan and I will both be available to very
carefully go about this.
Ro
de, will be going down some time in early or mid-July, so that's
almost a month away. Ryan and I are just planning and announcing this
freakishly early :)
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists
L yields:
An error has occurred: {"stack":"Error: ECONNREFUSED, Connection
refused\nat Socket._onConnect (net.js:602:18)\nat
IOWatcher.onWritable [as callback]
(net.js:186:12)","message":"ECONNREFUSED, Connection
refused","errno&qu
e fixed while
> still an extension, or it can remain jumpy in core.
>
That's not entirely accurate. If it's in core, we can add some of the
container divs in the HTML, reducing the jumpiness.
Roan Kattouw (Catrope)
___
Wikitech-l mailin
e
> page content. The regular wiki api gives us pages with wiki markup within
> it.
>
Do you know about api.php?action=parse&page=Somepage ? That'll give
you the HTML of the page, among other things.
Roan Kattouw (Catrope)
___
Wikitec
k your arguments made much sense.
> Even if it's 2-3 hours of work, I still would prefer that a volunteer
> gets involved in this area. Tim in particular has an overabundance of
> 2-3 hour tasks.
>
Yeah, that's true. A brief assessment by Tim as to whether this is as
easy a
t; take this on? I would very much prefer if this were a volunteer rather than
> a WMF staff member.
>
Why don't we first ask Tim how complicated it would be, and get
someone else to do it if it's more than 2-3 hours of work? I'm also
not sure the scripts Tim uses to create
p page, but that doesn't mean it's not being worked on :)
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
id you see the Etherpad in which Mark Hershberger assigned certain
paths to certain people?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
although more recent fixes may not be included. Max
or Krinkle can probably shed more light on this.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jun 6, 2011 at 4:21 PM, Aryeh Gregor
wrote:
> Hmm, interesting approach. Basically a postprocessor like I was
> thinking of, except simpler. I was thinking you'd insert special
> markers into the HTML that you'd replace later. But I can't think of
> any ways you'd get mismatches with yo
On Fri, Jun 3, 2011 at 10:35 PM, Mono mium wrote:
> Anyone can upgrade, Chad. It's not hard and any sane IT department
> should have done it six years ago.
>
That doesn't mean we should punish people that work for a company with
a less sane IT department.
Ro
revision history tomorrow to check why they were introduced in
the first place.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
browsing experience because you are
> using Internet Explorer 6" followed by a dump of the raw wikitext with any
> angle brackets replaced by < and >.
Could be cool, except we have caching proxies (Squid for api.php,
Varnish for load.php) between us and the IE users, and I'm n
by
me last night his time, and my guess is he'll probably implement it
this morning his time. But I'll leave it up to him to elaborate on
that.
Your ideas to secure api.php output against HTML abuse are
interesting, but I don't think the txt and dbg formats can be fixed
they happen thousands of miles from my desk so working
for WMF doesn't help me there), that there isn't a lot of attention
given to this. Whether that's actually the case or just the impression
that's being created due to lack
That person should not
be subject to the 20% rule, but should be spending as much time on it
as is needed to get stuff done. This position could probably be
rotated within the gen eng group.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
pend 1/5,
1/4 or even 1/3 or whatever on reviewing and deploying code in
general, and that this means they're that much less available for
project work or whatever else is competing for their time.
Roan Kattouw (Catrope)
___
Wikitech-l mail
nt dev experience and have shown potential,
not if we just grabbed them off the proverbial street and they're just
getting their feet wet with MediaWiki.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
up your breakages in within 48 hours of
> putting your original patch in, it must not have been very important.
>
+1. Serious breakage should be reverted on sight, however.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
week and we're all screwed.
So yes, before we implement this we need to 1) ensure that reviewers
spend enough time reviewing and 2) figure out what to do with
one-reviewer situations.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
out mine?)
* not enough man-hours spent on keeping up with new commits
** ...presumably because employed people aren't given the time to work
on it and/or made to work on it
** ...and because some of our reviewers are college students working
part-time (fortunately I'll graduate soon and have
. The gap between trunk and deployment means that
not everything can be updated (LU doesn't like it when message files
are renamed, and will refuse to update messages whose English version
has changed). However, most messages are fairly stable, so this
process works fairly well in practice.
.6.0 were fixed in 1.6.1, so I think most usages should
be fine.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
t; to me the location of that file, I could do the rest.
>
Did you know about http://noc.wikimedia.org/conf/all.dblist ?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
support this?
>
Have you seen http://www.mediawiki.org/wiki/Extension:WebFonts ?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
hile in
Japan hits the Tampa cluster, and someone visiting ja.wikipedia.org
while in France hits the Amsterdam cluster. In fact, when British and
American users view en.wikipedia.org, they view the same wiki through
different clusters.
Roan Kattouw (Catrope)
_
Foo&action=edit to
/edit/Foo , and it so happens 'view' is the default value for the
&action= parameter. And as you probably know stuff like action=edit
isn't localized either.
Roan Kattouw (Catrope)
___
Wikitech-l ma
On Tue, May 10, 2011 at 8:52 PM, Brion Vibber wrote:
> Any other nice poster-size visualizations hiding around?
>
I know it's not a visualization, but we could hunt down all xkcd
comics that reference Wikipedia and combine those into a poster or
something.
Roan Katto
) parser
don't necessarily need to know as much, so some gains could possibly
be made there.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Sure, but those aren't typically mixed with "real" changes in the same
edit. That's what was hard: spotting the actual changes in the midst
of all the normalization noise.
Roan Kattouw (Catrope)
___
Wikitech-l mailing l
nd the client side has been extended
> and patched. RTE is probably a good name for it, since that's what
> they call it.
>
Well that just speaks to how ancient my experience with it is, I guess.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
t the issues when introducing FCKeditor to
an existing wikitext 'codebase'. I hear it's fairly decent when used
from the start, but I'm not familiar enough with it to comment on
that.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
W
months, but
that's entirely due to wildly different latencies. The branch points
would be mostly regular though.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
k it would
> put us in a really good place to move forward into 2012, and help get us back
> into a somewhat regular release pattern.
>
I agree and applaud this goal, though per the above I'm not entirely
sure we mean the same thing when we say "regular release pattern".
suming we
branch 1.18 really soon now, which I think we should do, cause if we
wait for tool ong it'll just be another 1.17. 1.19 for November might
be a little bit tight but I guess we could shoot for it.
Roan Kattouw (Catrope)
___
Wikitech
t some tasks to Sam and
Chad to prepare for 1.16.5 and 1.17beta1, which Tim said should be
first priority. So we have some parallelization going on right now.
> Thoughts?
>
More documentation == good :)
Roan Kattouw (Catrope)
___
Wikitech-l maili
that I can see. That informs me. Is it part of the native
> system?
catrope@fenari:/home/wikipedia/common/php$ djvuextract --version
DJVUEXTRACT --- DjVuLibre-3.5.20
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@l
doing so.
>
Presumably it'll pass a referer header, which means the 3rd-party site
would know who (IP and account, if they have one on their site, like
on Facebook) visited which Wikipedia page when. I'm not very familiar
with the privacy policy, but I'm pretty sure this is shady a
g my opinions better than I could;
cheesy-sounding but true :P
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ths (3-4 releases/yr) is better, but I'm sure we can work
out a number. Your point that release cycle length should be
consciously and carefully decided on is a very good one, and I'm sorry
I hijacked it with my release latency argument.
Roan Kattouw (Catrope)
in
time, we always have a release branch that's being stabilized, which
means we have to perpetually maintain three branches (trunk,
deployment, release) instead of two, and are always in the process of
preparing a release. I don't like that idea, and I think it's
unnecessary.
Roan
t up-to-date.
>
The point I was trying to make was that July is by no means "soon and
early" in my book. It's three months away, which is way to long.
Setting a date is nice, but if we can get a release out before the set
date, that's a good thing, and I think we can (and /shou
27;t it be cleaner to just name the files RELEASE-NOTES-1.18 and
so on? We can do the rename-and-move-stuff-to-HISTORY thing right
before we release.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
terested to hear how unpaid
developers feel about that, as some of them have called out this
practice as undesirable back in September.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ke it dual-compatible.
See
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/ResourceLoader/Documentation/Using_with_extensions
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ion is not should we support IE6, it is just that I wonder about
> what our numbers show.
According to http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
, IE6 is 3.65% of our traffic. There is no per-country breakdown of
browsers that I know of, though, maybe Erik Z could b
it works, great,
if it doesn't, tough luck" is 0.5%. However, that's just for JS
enhancements; it's my opinion that at least reading Wikipedia should
be possible (i.e. not severely broken) in almost every browser.
Roan Kattouw (Catrope)
__
e?
>
Could be, I don't know. This is just something Tim told me like two
years ago, it might not even be accurate anymore.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
do part of the work only one
and cache the intermediate result.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ok into some hook that makes sense for your use case, and call addModule()
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
list, not a technical list.
The icons can be found at
http://bits.wikimedia.org/skins-1.5/vector/images/external-link-ltr-icon.png
and http://bits.wikimedia.org/skins-1.5/vector/images/external-link-rtl-icon.png
Roan Kattouw (Catrope)
___
t look at ApiBase::makeHelpMsgParameters()
> how this is handled by the documentation generator.
>
I said this on IRC but I'll repeat it here: the API exposes the data
from getFinalParamDescription() and friends through action=paraminfo.
Roan Kattouw (Catrope)
__
and reverting a *volunteer* developer's revision simply
because *paid* reviewers (most of them are paid anyway) didn't get
around to reviewing it is the kind of dickish behavior that will scare
off volunteers very effectively.
Roan Kattouw (Catrope)
___
upport working (1.18? 1.19?).
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2011/3/27 Schneelocke :
> Hi everyone,
>
> did the SSL certificate for secure.wikimedia.org expire?
>
It did, yes. Informing our ops department, they should be able to sort
this out quickly.
Roan Kattouw (Catrope)
___
Wikitech-l mailing lis
reviewer allocation, discipline and
assignment).
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
(e.g. schedule around school for people like me, schedule
Tim for Sunday cause that's his Monday, etc.) we could have a system
where the median time to review is like 24-48 hours.
These are my thoughts, and I'm definitely interested in talking about
this in Berlin, as Sumana suggest
think we will), but SVN is perfectly capable of
supporting something better than the ad-hoc non-paradigm we have now.
But more on that in its own thread, in its own time. I'd start a
discussion about this if I weren't so busy right now.
Roan Kattouw (Catrope)
_
ies", but maybe we can work
> towards this idea?
>
I was personally going for something more like assigning reviewers to
MW components, paths, time slots, or some combination thereof. But if
we're gonna have that discussion for real, let's have it
management they need. But that wasn't really
ever done in a permanent fashion.
Roan Kattouw (Catrope)
P.S.: The final paragraph is not meant to suggest that Brion was the
one and only code reviewer back in those days. Other people also
reviewed code, and I don't mean to marginalize the
n "Gadgets").
>
> Have fun!
>
That looks really useful, thanks!
Pulling it into core (or well, into the extension), as Brion
suggested, should be fairly easy, right?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.
first, and support Chad's suggestion that we try it with
phase3 first.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
d
to trunk, so TWN will be behind the curve a little bit. But I'm not
convinced that's necessarily bad: it'll hopefully prevent poorly
organized or poorly translatable messages from making their way into
trunk, thereby making sur
point, let's not bite off too much the first time.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
+
>
Extensions in SVN but phase3 in git? That doesn't really make sense to
me, TBH. Would it really be the end of the world if we had phase3 in
one repo and all extensions in another repo?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikit
ut we currently use
uppercase because UCA requires packages that aren't currently
installed on the Apaches. I hear ops is working on upgrading all
Apaches to lucid, though, which will make installing those packages
much much easier.
Roan Kattouw (Catrope)
___
301 - 400 of 898 matches
Mail list logo
