Re: [Wikitech-l] Removing oneself from commits on gerrit

2013-10-14 Thread Federico Leva (Nemo)
Not that I know; you should ask it upstream 
https://code.google.com/p/gerrit/issues/list
However, due to https://code.google.com/p/gerrit/issues/detail?id=1300 , 
the kindest reviewers in our gerrit also leave a short comment that 
they're removing themselves because they're not interested: that also 
helps not being added again to the same changesets.


Nemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Inline bug report history in Bugzilla

2013-10-14 Thread Željko Filipin
On Sat, Oct 12, 2013 at 2:05 AM, Isarra Yos zhoris...@gmail.com wrote:

 So yeah, helpful for the majority, I'd say.


+1

Željko
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Removing oneself from commits on gerrit

2013-10-14 Thread Antoine Musso
Le 14/10/13 02:01, Jeroen De Dauw a écrit :
 Hey,
 
 I have a big pile of commits that I have been added as reviewer on Gerrit,
 most of which I really do not care about. As a result, the entirely list
 becomes pretty useless and is just being a big waste of screen space. I
 could go through all those commits one by one and remove myself from them,
 though that is rather tedious. Is there a way to remove such commits
 quickly from my review list by just clicking them in the list, or doing a
 select, select, select, remove selected thing?

Hello,

You can query Gerrit over ssh interactive shell. I have setup a small
bash function for that:

 $ declare -f gerrit
 gerrit ()
 {
if [ -z $1 ]; then
ARGS=--help;
else
ARGS=$@;
fi;
set -x;
ssh -p 29418 gerrit.wikimedia.org gerrit $ARGS;
set +x
 }

Get help with:  gerrit --help

I can query Gerrit from the command line:

 gerrit query reviewer:'self' is:open


And one can remove self from a change with something like:

 gerrit set-reviewer COMMIT THERE --remove self

Pass '--format json' to get ... json output!

-- 
Antoine hashar Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bugzilla Weekly Report

2013-10-14 Thread Željko Filipin
On Mon, Oct 14, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote:

 MediaWiki Bugzilla Report for October 07, 2013 - October 14, 2013


Fresh charts are available at Bugzilla Weekly Report page[1]. Please let me
know (on or off list) if you find them useful. I am thinking should I
continue updating them or not.

Željko
--
1: https://www.mediawiki.org/wiki/Bugzilla_Weekly_Report
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Officially supported MediaWiki hosting service?

2013-10-14 Thread JFC Morfin

At 20:11 01/10/2013, Brion Vibber wrote:

Content-Transfer-Encoding: base64Question for the group:

Would an officially supported general-purpose MediaWiki hosting service be
useful to people who would like to run wikis, but don't have the time,
expertise, or resources to maintain their own installation?

If so, what can we (as interested parties in MediaWiki development and use)
do to make this happen?


Brion,

I am a lead user, i.e. not a competent nor professionnal developper, 
but someone with a need that he intends to address himself if there 
is no other way (I did it several times including once a distributed 
real time multimachine OS based on QNX, a 3.000 sites experimentation, etc.).


I observe that most of my current needs would be solved through what 
I name intellipages, i.e. intelligent standalone (single page wiki) 
or grouped (billion page wiki) pages plus a content centered 
accessing solution (can be a DDDS or semantic access). My needs are 
compacity, ubiquity, versatility, mobility, access security, backup, 
simplicity, replication, etc. I am not interested in wiki softwares: 
I am interested in what can be updated on a wiki page. I currently 
run more than 30 personnal working specialized [media]wikis (not big 
ones, often created in a few minutes and updated as time goes). I 
have queries from many people who would like to work the same. I have 
projects for many of them. With extensions.


My plan (I am beginning, so may be I will discover this cannot work) 
is to start from an existing wiki softaculous configuration on my 
windows machine and a copy of the same on my linux hosting company. 
As I did not find an A to Z architectural description manual, my 
target is to discover it by reverse engineering of the programs and 
databases relations. The target is to understand how to split the 
whole thing in two parts: a wiki craddle (software 
programs/protocols) and wiki containers (data, metadata, syllodata) I 
can (plural) dock, plug and play in the craddle. In the process I 
will probably need to document an interwiki protocol to suppervise 
the whole thing and the parallel/remote 
replication/backup/local-global-updating.


The cradre is what is to be updated by developpers. The content is 
what is to be updated, replicated and backuped by users. The 
cradle/container development ballance to be advised by architects. 
The probable value added services by (paid/non-profit) operators.


Hope this possibly crazy input might help.

jfc





[Please do not consider the existence of this email to imply that only
regular posters on wikitech-l are allowed to read, comment on, or give
opinions in this matter -- on the contrary, wider input is being requested.
Please forward this question to anyone to whom it may be of interest. If
you would like to get more input from other people, please feel free to
contact them on your own, with or without a forward of this mail, and to
make follow-up posts or comments as you need or want to. Please feel free
to modify the question, the idea, the proposal, or make comments or
additions. Be bold and get involved!]

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Inline bug report history in Bugzilla

2013-10-14 Thread Andre Klapper
On Fri, 2013-10-11 at 16:44 -0700, Quim Gil wrote:
 On 10/11/2013 03:37 PM, Andre Klapper wrote:
  I failed to make up my mind if it's helpful for the *majority* of
  Bugzilla users (reporters, testers, triagers, developers, managers) or
  if it might clutter the Comments view too much for some people, so I
  kept it as an opt-in setting.
  I'm happy to revise but don't know how I could find out. :)
 
 I think it's useful for some and instructive for the rest.

Thanks everybody for the helpful feedback.

Inline history functionality is enabled by default now for every user
who is logged into Bugzilla. 

Bugzilla users can switch it off again by setting When viewing a bug,
show all bug activity to Off on
https://bugzilla.wikimedia.org/userprefs.cgi?tab=settings

Cheers,
andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Inline bug report history in Bugzilla

2013-10-14 Thread Chad
On Mon, Oct 14, 2013 at 1:26 AM, Željko Filipin zfili...@wikimedia.orgwrote:

 On Sat, Oct 12, 2013 at 2:05 AM, Isarra Yos zhoris...@gmail.com wrote:

  So yeah, helpful for the majority, I'd say.


 +1


I guess I'm in the minority then. That's really cluttered and
gives me no useful information. Glad there's a way to turn
it back off :D

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Inline bug report history in Bugzilla

2013-10-14 Thread David Gerard
On 30 September 2013 16:01, Andre Klapper aklap...@wikimedia.org wrote:

 if you have found yourself clicking the History link in Bugzilla
 tickets way too often (to check who has set the Priority, or who has
 changed the assignee and when), Bugzilla now has an opt-in to display
 such metadata changes inline, between the comments of the bug report.


This is the BEST THING EVER, something I've wished was in Bugzillas
for ages and had no idea it was a config option away. Thank you!


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bugzilla Weekly Report

2013-10-14 Thread Antoine Musso
Le 14/10/13 12:56, Željko Filipin a écrit :
 On Mon, Oct 14, 2013 at 5:00 AM, reporter 
 repor...@kaulen.wikimedia.orgwrote:
 
 MediaWiki Bugzilla Report for October 07, 2013 - October 14, 2013

 
 Fresh charts are available at Bugzilla Weekly Report page[1]. Please let me
 know (on or off list) if you find them useful. I am thinking should I
 continue updating them or not.

If you are doing them manually, we might want to either automatize it or
build a more robust dashboard :-]

-- 
Antoine hashar Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Officially supported MediaWiki hosting service?

2013-10-14 Thread Quim Gil

On 10/02/2013 06:33 PM, Mark A. Hershberger wrote:

Did you see the Orain wikifarm? https://meta.orain.org/


No, I hadn't. But I followed your advice, I checked it out, tested the 
service with a wiki that some friends wanted to create and got to know 
the main contributors. Thank you! It's a very interesting community 
project run by wikipedians that love MediaWiki.


In fact I find it has some relation to this discussion and the 
possibilities suggested by Brion, Ori, Ryan, Mark... You are talking 
about an affordable Turbo service for power users and they are providing 
a free Diesel service for anybody.


But no just any diesel, check

https://meta.orain.org/wiki/Special:Version
MediaWiki 1.22wmf16, MariaDB, Scribunto and more if you ask for it.

and see also their projects to maintain their farm at
https://github.com/Orain
https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/tasks/main.yml

These people are clearly aligned with what this community is developing. 
They also seem to be having a similar vision about maintaining instances 
pulling from repositories, etc. If some of you think they could improve 
their approach I'm sure they would be happy to listen and discuss.


Now I imagine the combination of this free-for-all service with the 
affordable DIY setup you were describing and I see a great service for 
the community, yes.


Post Disclaimer: today I donated to Orain.org to support the initiative. 
An hour later they convinced me to move my pet project there. I wasn't 
amused about having to update core and extensions when MW 1.22 was out. 
Now my site is running basically the latest you can find out of the 
Wikimedia servers. And I will concentrate on my users and content. Happy.


--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l