FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Infrastructure

 
 
LinkBack Thread Tools
 
Old 01-13-2011, 03:05 PM
Adam Williamson
 
Default Wiki extension request

Hi, everyone. I'd like to ask about adding an extension to the Fedora
wiki instance.

Many of you may have noticed the package-specific test case project I've
been working on lately - https://fedorahosted.org/fedora-qa/ticket/154 .
Part of the plan for this project is to allow tools such as Bodhi to use
mediawiki categories to figure out certain sets of test cases. One
important one is 'all critical path test cases for package foo'.
However, this requires the ability to do multi-category search in the
wiki - find all pages that are members of two (or more) different
categories.

We've identified a couple of extensions which can potentially achieve
this:

http://www.mediawiki.org/wiki/Extension:Multi-Category_Search
http://www.mediawiki.org/wiki/ExtensionynamicPageList_%28Wikimedia%29

I'd like to ask that we look at including one of these (or someone tell
me that we already do :>).

There are a couple of concerns that I don't have sufficient expertise to
address. There would need to be some kind of, I guess, API access to the
searches, so that an external tool could do the search - both extensions
seem rather geared to doing the search entirely within the Wiki, for
instance, including the results of the search in another page. I don't
know how to tell which, if either, extension is most suited to this. The
other concern is recursion - does either extension handle this case:

page is a member of categories A and Z, but not directly of category B
category A is a member of category B

if searching for 'all pages that are in category B and Z', does the page
show up? For our purposes I'd like that the be the case.

If anyone can help with this it'd be greatly appreciated! Thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 01-13-2011, 04:09 PM
Ian Weller
 
Default Wiki extension request

On Thu, Jan 13, 2011 at 04:05:37PM +0000, Adam Williamson wrote:
> We've identified a couple of extensions which can potentially achieve
> this:
>
> http://www.mediawiki.org/wiki/Extension:Multi-Category_Search
> http://www.mediawiki.org/wiki/ExtensionynamicPageList_%28Wikimedia%29

[snip]

> There are a couple of concerns that I don't have sufficient expertise to
> address. There would need to be some kind of, I guess, API access to the
> searches, so that an external tool could do the search - both extensions
> seem rather geared to doing the search entirely within the Wiki, for
> instance, including the results of the search in another page. I don't
> know how to tell which, if either, extension is most suited to this. The
> other concern is recursion - does either extension handle this case:
>
> page is a member of categories A and Z, but not directly of category B
> category A is a member of category B
>
> if searching for 'all pages that are in category B and Z', does the page
> show up? For our purposes I'd like that the be the case.

If you only need multi-category searching in the API, that extension
won't help any, since it doesn't appear to expose anything over the API.

Using the API, however, you can get a list of pages within categories,
and then just use whatever programming language you're using to merge
them together on the client side, not the server side. You can read the
docs for list=categorymembers on fp.o/w/api.php, or we can hack on it at
FUDCon at some point.

(And, if you program it yourself, you can make the merging work however
you want.)

DPL does the same thing, but can be included in any page on the wiki.
That might be useful, if you want that information to show up on the
wiki, but if you're still just wanting to use the API and have it show
up elsewhere, it's not useful at all.

On a more general note, I think we are somewhat shy of having too many
extensions on our wiki instance, because compatibility can break on wiki
upgrades and can also slow down the wiki (one of the main reasons we had
such slowdowns with MoinMoin, IIRC, was too many plugin/extension type
things). Additionally, I've been talking with smooge to get MW upgraded
to 1.16 soon, which will include highly improved API support.

--
Ian Weller <ian@ianweller.org>
Where open source multiplies: http://opensource.com
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 01-17-2011, 04:15 PM
Adam Williamson
 
Default Wiki extension request

On Thu, 2011-01-13 at 11:09 -0600, Ian Weller wrote:

> If you only need multi-category searching in the API, that extension
> won't help any, since it doesn't appear to expose anything over the API.

OK, thanks.

> Using the API, however, you can get a list of pages within categories,
> and then just use whatever programming language you're using to merge
> them together on the client side, not the server side. You can read the
> docs for list=categorymembers on fp.o/w/api.php, or we can hack on it at
> FUDCon at some point.

Sure, the only issue that we're worried about with that is that it will
lead to unnecessarily complex implementation issues. The types of
searches we want to do for the test case categorization system are
pretty static - it'll always be a certain type of category combination
that needs querying - so having each client implement it client-side
seems like unnecessary work and may lead to more breakage than
necessary, so we thought it'd work best to present a common interface
for doing this, in some way - a recommended method for external tools to
use which will be the same for all of them, so we can make sure it's
always robust.

James has volunteered to look at perhaps implementing what we want into
python-simplemediawiki , which might suffice - we could set up a method
in that, and then just recommend all external tools use that method to
do the test case discovery.

> DPL does the same thing, but can be included in any page on the wiki.
> That might be useful, if you want that information to show up on the
> wiki, but if you're still just wanting to use the API and have it show
> up elsewhere, it's not useful at all.

yeah, that may be useful in some way, but it's not really the goal here,
so it's probably not worth looking at unless and until we have some
specific need for it.

> On a more general note, I think we are somewhat shy of having too many
> extensions on our wiki instance, because compatibility can break on wiki
> upgrades and can also slow down the wiki (one of the main reasons we had
> such slowdowns with MoinMoin, IIRC, was too many plugin/extension type
> things). Additionally, I've been talking with smooge to get MW upgraded
> to 1.16 soon, which will include highly improved API support.

Cool, thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 

Thread Tools




All times are GMT. The time now is 06:00 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org