I found a bug into pywikipedia library, wikivoyage-family.py.
Into the first class, there's a wrong line that blocks login for bots.:
self.name="Wikivoyage"
The right line should be:
self.name="wikivoyage"
with lower case; fixing the script into my local copy of pywikipedia
library the bug disappears and login runs.
Can please one of you post a bug into Bugzilla (I can't... I hate Bugzilla
and I never use it :-( )? In the meantime, I'll fix the bug manually at
any pywikipedia update.
Thanks!
Alex brollo
Hello,
As you surely have noticed, the unit tests for mediawiki/core are no
more run when a patch is submitted.
I have just enabled a feature that whitelist people to have unit tests
run for them on patch submission. The patch still need to be reviewed
and approved with a CR+2 though.
Basically any user with a @wikimedia.org or @wikimedia.de email address
is whitelisted by default. I have also added a few contractors using
their personal emails and several long term users.
The related change is:
https://gerrit.wikimedia.org/r/#/c/39310/
This is only enabled for mediawiki/core for now, I will look at applying
such a whitelist on extensions too in January.
There is no process to be added in the whitelist, I guess you could talk
about it on IRC. If there is no obvious veto there, you could probably
just amend layout.yaml in integration/zuul-config.git file and get it
approved :)
cheers,
--
Antoine "hashar" Musso
Hello!
28 SEPTEMBER I've pushed minor changes to the gerrit, to the Drafts
extensions.
Since then I've corrected two of them ("uploaded patch set 2"), but
after that, nobody did the review. As I understand, Gerrit will abandon
changes after a month of inactivity, and it will come tomorrow...
The changes are really simple.
How to ask someone to really do the review? Does Gerrit have such
function?
Thanks in advance,
Vitaliy Filippov
bugzilla.wikimedia.org is operational again and is now running the
latest stable version (4.2.4, before was 4.0.9).
Big thanks to Daniel Zahn from the ops team for upgrading!
All fame belongs to him!
I've done some quick testing, and to my surprise stuff like "Weekly bug
summary" did not break.
However, if you see new issues and problems please file a ticket:
http://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia&component=Bug…
The only (potential) regression is that we did not apply previous
changes to Bugmail.pm, described as "Wikimedia Hack! Pretend global
watchers are CCs so we can use their prefs to for instance ignore
CC-only mails."
New features and improvements of this Bugzilla version:
http://www.bugzilla.org/releases/4.2.4/release-notes.html#v42_feat
Happy bug reporting!
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Two quotes from the last weeks:
Krenair in #mediawiki on Nov 30 22:46:47:
"andre__, what is stopping us from making a 'patch in
gerrit' bug status with a link to the change?"
Ryan Kaldari in
https://bugzilla.wikimedia.org/show_bug.cgi?id=42470#c4 :
"I use Bugzilla as a to-do list. [...] If Bugzilla had a 'Waiting
for Merge' status, this wouldn't be as much of an issue."
Currently there is a "patch-in-gerrit" keyword in Bugzilla. When a bug
report ends up as RESOLVED FIXED there usually had been a codefix in
Gerrit that got merged. Hence "patch in gerrit" could be considered
another state on the journey of a bug from reporting to fixing.
And Bugzilla allows adding stati (stuff like "NEW" or "RESOLVED").
I'm proposing adding a new status like
PATCH_TO_REVIEW or
WAITING_FOR_MERGE or
FIX_AWAITING_MERGE or
REVIEW_IN_PROGRESS
or something like this (bikeshed, yay!). Probably the first.
The status would replace the "patch-in-gerrit" keyword and you would set
it in Bugzilla when you have pushed a patch into Gerrit for review that
is expected to fix the reported bug. (Not sure what to do about partial
fixes, but that's a cornercase.)
Obviously, once the patch got merged you'd close the corresponding bug
report as RESOLVED FIXED. No changes here.
"Bug report life cycle": The new status could be set from {UNCONFIRMED,
NEW, ASSIGNED, REOPENED} and could be transfered into {UNCONFIRMED, NEW,
ASSIGNED, REOPENED, RESOLVED}.
Comments / arguments?
andre
PS: Underscores in the status name are needed as far as I know.
Please keep opinions for other email threads that are about renaming
some other Bugzilla stati, or better linking between Bugzilla and
Gerrit, or automatic status setting in Bugzilla when a patch is in
Gerrit, or somehow distinguishing in Bugzilla between the situations
"fix merged into code repository", "fix released in MW tarball" and "fix
deployed on an MW server". I hereby thank you kindly! :)
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Hi guys!
I'm writing the EditPage::showEditForm:fields and I want to get a
Request object. The use of wgRequest considered to be deprecated, so
how is it possible to get request object in my hook function?
static public function showBacklinks($editpage, &$output){
return true;
}
Cheers,
Yury Katkov, WikiVote
Hi all,
Since the Concise Wikipedia proposal[1] has been mentioned in the last two
Signpost editions[2][3] (and after being nudged by Sumana), I figured I'd
drop a note here in case anyone will be interested in trying out a demo I
set up to explore the idea, espoused by many in the proposal discussion,
that such a proposal should not be a separate project, but integrate with
Wikipedia's lead/introduction sections instead.
I called my demo "Primerpedia" (suggestions for better names welcome, see
[4]), and it can be accessed here: http://waldir.github.com/primerpedia
It uses the API to fetch the lead section of an article (currently only
loading random articles is implemented), and displays it isolated, which
should provide a good way to test its expected self-containing, summarizing
properties, as defined in the MOS:LEAD guideline.
I am aware of several shortcomings in the current implementation and plan
to improve it further; any suggestions or issue reports are welcome at [5]
or directly on this thread for convenience.
--Waldir
1. https://meta.wikimedia.org/wiki/Concise_Wikipedia
2.
https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-12-03/Discu…
3.
https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-12-17/Discu…
4. https://github.com/waldir/primerpedia/wiki
5. https://github.com/waldir/primerpedia/issues
Hello,
We would like to clarify the reason we changed Jenkins to no longer run unit
tests on patch submission.
We had to defer code execution to after CR+2 for security reasons. If unit tests
were ran on submission that meant anyone with a labs account could effectively
get shell access on the server.
Because LDAP accounts are now up for open registration (aka free Labs accounts,
and by extend permission to submit patches to Gerrit), that also meant the whole
world would be able to get shell access on the server (via PHP/Nodejs/ant/bash
to infinity and beyond).
This issue will be definitely solved by isolating tests in dedicated virtual
machines for each run. We are investigating Vagrant.
Restricting unit tests is simpler and faster to implement over all the Vagrant
engineering. So "running tests after CR+2" is a temporary measure until the
implementation of Vagrant sandboxes in Jenkins builds is ready.
So, in conclusion: Unit tests will be run again on patch submission once we have
finished integrating Vagrant in Jenkins.
-- The CI team
Antoine & Timo
Hello,
After some of the recent changes to the Gerrit workflow with
Jenkins and Zuul, we've received some complaints about how
Jenkins is reporting its results. Right now, it is using both the
"Verified" and "Code Review" categories. This is bad because
it gives you a false sense of what has been reviewed for most
queries and dashboards.
So tomorrow, we are going to tweak the way Jenkins reports
back to Gerrit by extending the Verified vote range from -1..+1
to -2..+2. This will allow Jenkins to give a range of results, all
in the Verified category (and keeping it out of Code Review,
which will once again only be for humans). The new Verified
range will behave as Code Review does now (-2 is veto, +2 for
submit).
Linting jobs will receive Verified ±1 votes. Unit tests jobs
(triggered after someone votes CR+2, as it currently is) will
receive Verified ±2 votes.
So, anyone who's got Verified permissions on a repository
(project owners, this means you), beginning tomorrow at around
13:00 UTC you will see extended Verified options. We'll let
everyone know when this is complete.
--
The Gerrit/CI guys
Chad & Antoine
Hello,
I have upgraded PHPUnit 3.7.10 on pour Jenkins installation. It already
ran a full test suite of mediawiki/core without any trouble.
If you get any trouble with it, please open a bug under Wikimedia >
Testing Infrastructure.
For reference the bug requesting upgrade was:
https://bugzilla.wikimedia.org/42724
--
Antoine "hashar" Musso