Hey,
This is something I've come across several times before when deprecating
functions: people want different behaviour with regard to the warnings they
get. Typically what people want can be split into two groups:
Weak deprecation: The function is documented as being deprecated but no
wfDeprecated is put in
* Pro: People do not get flooded with deprecation warnings when the
function is still in use at many places.
* Con: It's impossible to actually get warnings for this usage of this
function when desired for some purpose. When writing new code, it'd be good
to be able to notice you're using deprecated functions.
* Con: Many people won't notice they are using deprecated code at all,
since not everyone is using an IDE highlighting deprecation and those that
don't are definitely not looking at the definition of every function they
use.
Strong deprecation: The function is documented as being deprecated and
wfDeprecated is put in.
* Pros and Cons: opposite of the above
It's clear each that for different people the same approach might not be
preferred. Discussion arises when some people do not want something to be
strongly deprecated. What about introducing a soft deprecation function (ie
wfSoftDeprecated) that calls wfDeprecated with an additional argument
specifying it's a soft deprecation call, which by default does not result
in any warnings or notices, but can by means of some setting be turned on
by those that want to get them? Such a setting could either be a boolean,
int (ie show warnings above this level) or some whitelist of softly
deprecated functions one wants to get warnings for. Seems to be pretty
trivial to accommodate both groups here, and get rid of the silly
discussions.
Any thoughts?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hey,
Siebrand, one of our i18n overloards, is stating that some wfMsg function
has been deprecated here:
https://gerrit.wikimedia.org/r/#/c/17055/4/SRF_Utils.php
However, the functions do definitely not have any deprecation notice. Do we
want to deprecate them at this point? If so, @deprecated and wfDeprecated
should be added. And if not, it's probably still good to mention using the
newer methods if your code can depend on 1.18 or later in the function docs.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
On 6 August 2012 17:46, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> Verify what David said (I'm not technical, but it matches the description
> I've been given). Our ops guys and girls are currently poking things, which
> is slowing down a larger/more official announcement, but I'll see what I
> can do.
The "1:06" is from Reedy, the "waiting on vendor postmortem" is from
Leslie Carr.
The BBC article is ... well, I have said some of the words in those
quotes during my life. The headline is accurate ...
- d.
Here is a quick suggestion. These should be more neutral and easy on the
eyes if you keep seeing a lot of gerrit. I wish there was a simple way to
change the values in the css and upload a preview, but i did a view source
on gerrit and I received quite a fright.
Leaving it to someone else to show us how this scheme looks:
1) backgroundColor -- no change
2) topMenuColor -- #DBDCFF
3) textColor -- no change (unless its possible to have different classes
for different texts)
4) trimColor -- optional #A4A5BF
5) selectionColor -- #FFE4CE, alternate #F1F1FF
--
j.mp/ArunGanesh
... so I might as well tell you too. Info gathered by joggling the
elbows of the people on #wikimedia-tech actually doing the work:
This was two overland cables between Tampa and Virginia (Washington
DC, to be precise). *Both* cables were cut, near the Tampa end. The
"redundant" fibre wasn't redundant. Currently awaiting the vendor
postmortem.
The cables were broken for 1 hour 6 minutes, but it's taken another
hour to bring up basic service. Some stuff's still broken. Search and
API (hence mobile) are back now. It'll all be back in due course.
The WMF office in San Francisco should be getting into work in the
next hour or so ... should have more detail then.
- d.
The BBC asks:
* where was the cut - on land, at sea? Do we know more about the cut?
* when did it start and when did it end?
* any other useful information?
This one may rate a short tech blog post :-)
- d.
On 6 August 2012 15:52, WereSpielChequers <werespielchequers(a)gmail.com> wrote:
> Hi, after crashing an hour or so ago EN Wikipedia has started to come back
> but with a really strange appearance - less usable than Vector. Rumour has
> it that someone cut through a fibre optic cable in Florida, so far none of
> the parties to various incidents on the Dwamah boards have fessed up as
> responsible. If anyone in the know could give more details it would be nice.
Please do, it's making the news already (Mashable, CNet) and the BBC
just called to ask about it :-)
Front page is back for me, fwiw.
- d.
Hi - I'm Al Snow.
Applied for the Bug Wrangler position a week ago. Started today setting up accounts and reading about the internals. Also did some archaeology on Bugzilla and have some questions.Appears CLOSED status is not used much - do we stop at RESOLVED or VERIFIED status? How about PRIORITY? See lots of UNPRIORITIZED that have a active (ACTIVE, RESOLVED) status. Will double-check docs, but unclear how DUPLICATE tickets are set to CLOSED.How long does a ticket stay in one status before we need to flag it?
Created a couple of personal Bugzilla monitors (whiners), but any help with bug triage dashboard/graphs/reports/wizards/extensions would be appreciated.
Also saw reference to Bug Squad in 2012-2013 Goals. (Thanks - Julian)
......................................................................My bug triage ideas, beside the Bug Squad, include looking into:Semi-automatic detection of duplicates (see Bugzilla e-group)Semi-automatic assignment of Assignee (saw some external references)Create wizard to improve bug creation (similar to Google's BITE project ;>)
Wrestle that bug to the ground!Al
PS. Today's notes - if you have questions about what I found in the last several days.
Hi all,
with this Email I want to start the discussion on how to
operationalize the deployment of Wikidata. This Email gives a general
outline, and a link to the page on Meta where I will collect the
results of this discussion. Discussion, feedback and comments are
welcome.
The goal for Wikidata is to release early, release often, and to
eventually follow WMF's lead with their bi-weekly deployment cycle.
The very first version of Wikidata to deploy is almost there. We still
have a number of bugs and wrinkles we are polishing, but in general we
are ready to start moving towards deployment. This will lead to a very
organic introduction of Wikidata data into the Wikipedias. We can
react to problems and use cases early. I think a plan where we
implement the three phases completely and deploy them then is bound to
lead to a less widely accepted solution.
The suggestion is to deploy the following steps. This all still only
covers phase I.
* Step 1: start the Wikidata repository wiki. This only allows to add
language links, and they are not displayed anywhere yet.
* Step 2: deploy the Wikidata client extension on one language edition
of Wikipedia for testing (Q: How to select it?)
* Step 3: deploy the WIkidata client extension on a second language
edition of Wikipedia (Q: How to select it?)
* Step 4: deploy the Wikidata client extension on the English edition
of Wikipedia
* Step 5: deploy on all Wikipedias.
Details are on this page on Meta:
<http://meta.wikimedia.org/wiki/Wikidata/Notes/Deployment>
I would like to find the appropriate means to define how to implement
the above steps whether on this list or off it.
Even though Rob has given me unlimited license to be obnoxious on this
list about this, I will try not to. Mind the "try" :)
Cheers,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.