Hey,
I have a feature branch with two dozen commits which I merged into master
locally and now want to push directly to git. All commits have been
reviewed, so going via gerrit makes no sense. (In fact it complains about
the stuff already being closed it I try that.) When I try to do this, I get
the below message:
git push origin master
Counting objects: 102, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (80/80), done.
Writing objects: 100% (83/83), 36.01 KiB, done.
Total 83 (delta 49), reused 0 (delta 0)
remote: Resolving deltas: 100% (49/49)
remote: Processing changes: refs: 1, done
To ssh://review/mediawiki/extensions/SemanticMediaWiki.git
! [remote rejected] master -> master (can not update the reference as a
fast forward)
error: failed to push some refs to
'ssh://review/mediawiki/extensions/SemanticMediaWiki.git'
This is after I did a pull from origin master
git pull origin master
>From ssh://review/mediawiki/extensions/SemanticMediaWiki
* branch master -> FETCH_HEAD
Already up-to-date.
Anyone know what's going on and how I can fix this?
(I have gerrit rights to directly push to this repo.)
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
(Spun off the Advertising changes to MediaWiki messages in core.)
2012/12/4 S Page <spage(a)wikimedia.org>:
> I wrote a little script last night to check for the existence of the
> old and new messages, and it seems there are 205 wikis that did
> override welcomecreation (!!?), so ideally someone should find the
> [[Wikipedia:MediaWiki messages]] or [[Village pump (technical)]] page
> for those 205 wikis, or otherwise contact their admins. The list of
> wiki messages is at
> <https://www.mediawiki.org/wiki/User:S_Page_%28WMF%29/welcomecreation_messag…>
This made me feel very \o/.
Research about current customizations of messages on projects is
probably the number one thing that I'd like to see happen in the
Wikimedia dev community.
These customizations didn't go through the thorough user testing
process of the kind that your team does, but they are nevertheless a
wonderful source for ideas for improvements that can be useful for any
language, and for identifying things that communities need and the
software doesn't provide out of the box.
> I'm curious if any of those 205 wikis are doing inventive "Welcome
> aboard, now read a tutorial/say hi/fix a page/play in the sandbox"
> things. It's an area our team (Editor Engagement Experiments) cares
> about.
In the languages that I know (Hebrew, Russian, Catalan) - yes, mostly.
The most inventive is probably the Hebrew Wikipedia (
https://he.wikipedia.org/wiki/MediaWiki:Welcomecreation ), which has a
lot of graphics. It has three big buttons:
1."writing style tutorial for beginners" (equivalent of Wikipedia:Tutorial)
2. "adopt-a-user" (equiv. of Wikipedia:Adopt-a-user or Teahouse) /
"Help Desk" (equiv. of Wikipedia:Help desk)
3. Special:Preferences
Most customized welcome pages say a few words that are specific to the
project, such as "Welcome to the Russian Wikiversity. Sign up to your
school."
One message was just a punctuation correction that was made to its
primitive 2005 version. Things like this happen a lot, too.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi all,
Recently, in order to make a rather small user interface change (see bug
#42215), our team needed to replace MediaWiki:Welcomecreation with a new
message, MediaWiki:Welcomecreation-msg.
The new message contains all of the things MediaWiki normally inserts in
that message, and simply changes the header text. Simple enough.
My question here is... Is there a best practice for advertising changes to
MediaWiki messages like these?
This message, which is given to users once after they register, is
sometimes customized. We can go look and see which wikis have written
custom content, and inform them they need to migrate it to the new message.
But I was wondering if others have encountered this problem, and how they
dealt with it.
--
Steven Walling
https://wikimediafoundation.org/
All,
Mike Wang is joining us today as our part time Labs Ops Engineer
(consultant), based in Tampa, FL.
As a member of the Labs team, he will be working closely with Ryan Lane,
Andrew Bogott and Faidon Liambotis, to perform day-to-day labs support
duties such as systems administration and resolving user issues.
Prior to joining us, Mike was a Linux Administrator at Xcira Inc. and
Videogroup Distributor Inc., in Tampa. He grew up in China and where he
received a B.S. in Mathematics from Shanxi University and a M.S. in
Robotics from Beijing Institute of
Technology.
Please join us to welcome Mike and you can chat with him on our IRC
#wikimedia-operations and #wikimedia-labs channels - his nick is
'wangatlargo'.
Thanks,
CT Woo
After Sumana's summary of the wmf5 phase2 deployment (last Wednesday) at
http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064718.html
we ran into similar issues again yesterday night when deploying to
English Wikipedia (phase3).
According to Ryan in bug 42452 , this time "The problem seems to be that
ResourceLoader isn't delivering the updated CSS." Some minutes later
Ryan "touched and synced the startup.js and
ext.vector.collapsibleNav.css files. Seems to be working correctly now."
Still, we have several users that state that after purging their browser
cache they *still* face issues:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#What_just_…
Can anyone shed some light on how affected users can track down and help
to fix the underlying problems here, if possible?
What could users try, and which data could they provide?
Obviously I'd love to avoid ending up with the same situation (and
"lively" Village Pump discussions) again tomorrow when deploying wmf5 to
all other Wikipedias.
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
The deadline for submissions to the Outreach Program for Women was
reached yesterday and we have got 11 candidates:
http://www.mediawiki.org/wiki/Outreach_Program_for_Women#Candidates
The selection process and criteria are explained at
http://www.mediawiki.org/wiki/Outreach_Program_for_Women#Selection
Between now and Friday you (yes, you) are encouraged to endorse your
preferred participants in their User Talk pages. Ten minutes of your
time might bring 3 months of paid internship to a brilliant contributor!
This call goes especially for contributors to projects related to the
project proposals presented. This endorsement is also a good opportunity
to offer your support and help. Candidates can also request endorsement
from colleagues in projects where you are currently active. All input
data is useful as long as there is some way to identify who is endorsing.
We will use these endorsements in our evaluation for each candidate. The
most important factor of evaluation will be the confidence of the
mentors on each candidate accomplishing the goals of their proposals.
Your backing is relevant to register interests in a specific proposal
and also the help it might get from other contributors interested in the
same area. At the end the goal of the program is to see tasks
accomplished and (even more important) new members happily involved in
the community after the internship ends.
There is a private meeting with all the mentors this Friday. Make sure
your feedback is posted in their Talk pages by then.
The selected candidates will be announced on December 11, next Tuesday.
PS: Candidates are invited to introduce themselves in this list if they
wish. If you are here it's because you have done already a significant
amount of homework. W hope to see you around and active regardless of
the outcome of the selection! Congratulations and thank you for choosing
Wikimedia as your preferred project to contribute.
--
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation
Hi all!
I recently found that it is less than clear how numbers should be quoted/escaped
in SQL queries. Should DatabaseBase::addQuotes() be used, or rather just
inval(), to make sure it's really a number? What's the best practice?
Looking at DatabaseBase::makeList(), it seems that addQuotes() is used on all
values, string or not. So, what does addQuotes() actually do? Does it always add
quotes, turning the value into a string literal, or does it rather apply
whatever quoting/escaping is appropriate for the given data type?
addQuotes' documentation sais:
* If it's a string, adds quotes and backslashes
* Otherwise returns as-is
That's a plain LIE. Here's the code:
if ( $s === null ) {
return 'NULL';
} else {
# This will also quote numeric values. This should be harmless,
# and protects against weird problems that occur when they really
# _are_ strings such as article titles and string->number->string
# conversion is not 1:1.
return "'" . $this->strencode( $s ) . "'";
}
So, it actually always returns a quoted string literal, unless $s is null.
But is it true what the comment sais? Is it really always harmless to quote
numeric values? Will all database engines always magically convert them to
numbers before executing the query? If not, this may be causing table scans.
That would be bad - but I suppose someone would have noticed by now...
So... at the very least, addQuotes' documentation needs fixing. And perhaps it
would be nice to have an additional method that only applies the appropriate
quoting, e.g. escapeValue or some such - that's how addQuotes seems to be
currently used, but that's not what it actually does... What do you think?
-- daniel
PS: There's more fun. The DatabaseMssql class overrides addQuotes to support
Blob object. For the case $s is a Blob object, this code is used:
return "'" . $s->fetch( $s ) . "'";
The value is used raw, without any escaping. Looks like if there's a ' in the
blob, fun things will happen. Or am I missing something?
If last October we got a bunch of MediaWiki developer stats thanks to
the aggregation of data by Ohloh [1], now we are getting plenty more
stats from Bitergia, including data from bug reporting and mailing lists:
http://blog.bitergia.com/2012/12/03/complete-basic-analysis-of-mediawiki/
Bitergia is a company based in Madrid formed by a small team of
developers that have been working on FLOSS stats software for a long
time. All the tools they develop are free software publicly available
and open to contributions.
They have been kind enough to contribute some time and work setting up
stats for the MediaWiki community. They also welcome feedback about the
service and the data collected. I'm CCing Jesús M. González-Barahona,
who has been my regular contact for this task in the past weeks.
Al good news for http://www.mediawiki.org/wiki/Community_Metrics !
[1] https://www.ohloh.net/orgs/wikimedia
--
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation
El 03/12/12 22:45, Jesus M. Gonzalez-Barahona escribió:
> On Mon, 2012-12-03 at 21:04 +0100, Platonides wrote:
>> El 03/12/12 19:40, Federico Leva (Nemo) escribió:
>>> That data is hardly useful, it doesn't explain what it refers to
>
> I guess I missed your message, Federico.
He forgot to keep you in CC, so it was sent only to the mailing list.
>> I agree a glossary of each term would be useful.
>> It took me a while to realise that committers/closers/senders where the
>> terms used for users of git/bugzilla/mailing list.
>
> Well, in fact commiters are committers to the git repository (you also
> have authors, see below), closers are specifically ticket closers (you
> also have people opening or changing tickets) and senders are indeed
> senders of mailing list messages. We'll work to make this much more
> clear. Again, thanks for the suggestion.
>
>> They should track authors instead of committers, though (preferably
>> skipping merge commits)
>
> We do both. In the summary (main) page you have authors in the summary
> (orange) chart, since authors seemed more meaningful than committers.
> Same for the "blue" chart in that page. In the source code page you have
> committers (orange chart) and both authors and committers (blue charts),
> for a more detailed comparison.
I was specifically thinking in the table of Top committers.
Also, the summary page has an authors graph but
http://bitergia.com/public/previews/2012_11_mediawiki/scm.html has a
committers one.
When the committer is different than the author there are usually two
options:
- It was a merge and the committer is 'gerrit'.
- The patchset was (slightly) changed by the committer from the original
by the author.
There's also a less common one of committing a patch from a different
source, such as a bugzilla patch.
Number of commits by gerrit are meaningless, and committers with little
changes inflate some numbers but are not too useful. Number of comments
/ approvals in gerrit would be more appropiate than that.
Equally, the author field of merges should IMHO be ignore since that's
not a commit which really touches the code (could be measured in a
different statistic), so many commits produce two entries.
>> Seems that Jesús did a fine job.
>> It could be polished quite more with some local knowledge, merging
>> users, hiding bots, etc.
>
> Thanks a lot. We usually go, after this first stage, with that
> identification of bots, unification of identities, identification of
> large commits, classification of different kinds of tickets, etc. In
> this case, we were mainly testing the automated (first) stage: the
> second one, as you mention, usually needs some detailed knowledge about
> the project, and some manual intervention.
Sure. I wasn't intending to put pressure on you.
A few quirks I noticed:
- noreply(a)sourceforge.net is abusing its second place as sender (2525).
- I bet the two brion are the same, with different emails
(4561+1285=5846, wow!)
l10n-bot is indeed a bot.
On svn localisation commits weren't done with a specific account, but
you can look for commit messages like «Localisation updates for core and
extension messages from translatewiki.net»
Commits migrated from svn will have emails of
username(a)users.mediawiki.org All commits done on git use a different
one. Moreover, some people have used different mails (see other threads
on the mailing list about this in ohloh).
>> I would also change the layout of the summary page, making the graphs
>> larger and placing the tables below. Plus some cosmetics empty brackets,
>> missing name...
>
> This is a very good point, and something we didn't work too much into. I
> take note.
>
> Thanks a lot for the feedback!
You are welcome!
As announced for several days on bugzilla.wikimedia.org already,
bugzilla.wikimedia.org will be unavailable due to maintenance work on
Tuesday, December 04th from 18:00 UTC until max. 20:00 UTC (10:00 PST -
12:00 PST).
That starts now.
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/