Re: [Wikitech-l] Officially supported MediaWiki hosting service?
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
Re: [Wikitech-l] Bugzilla Weekly Report
Le 14/10/13 12:56, Željko Filipin a écrit : > On Mon, Oct 14, 2013 at 5:00 AM, reporter > wrote: > >> 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] Inline bug report history in Bugzilla
On 30 September 2013 16:01, Andre Klapper 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] Inline bug report history in Bugzilla
On Mon, Oct 14, 2013 at 1:26 AM, Željko Filipin wrote: > On Sat, Oct 12, 2013 at 2:05 AM, Isarra Yos 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
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] Officially supported MediaWiki hosting service?
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] Bugzilla Weekly Report
On Mon, Oct 14, 2013 at 5:00 AM, reporter wrote: > 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] Removing oneself from commits on gerrit
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 --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] Inline bug report history in Bugzilla
On Sat, Oct 12, 2013 at 2:05 AM, Isarra Yos 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
