headers
Raylton P. Sousa | 11 Feb 12:01
Picon
Gravatar

Regarding GSoC 2012

Hi *Aashish*, I'm one of authors of
BookManager<http://www.mediawiki.org/wiki/Extension:BookManager>and i
have a relatively large knowledge of the issues that comprise the
wikibooks/wikisource (and others),  I had thought to solve this problem I
don't have time and/or sufficient knowledge yet, I have several ideas I
have listed here<http://pt.wikibooks.org/wiki/Utilizador:Raylton_P._Sousa/Projetos/BookManager/Concep%C3%A7%C3%A3o_de_software>.
Can I help what is within my reach.

=D
Permalink | Reply | 0 comments |
headers
Rob Lanphier | 11 Feb 08:05
Picon
Gravatar

We're still in a code slush (Re: How to avoid a post-branch code slush)

Hi everyone,

I probably mistitled my last message in the "How to avoid a
post-branch code slush" thread.  There seems to be a misconception
that the code slush is over.

Please go back and read the thread.  The status quo is *there is still
a code slush*.  What this means:
1.  No big architectural changes without discussion.  Not merely "hey,
I sent a message, and no one responded", but as in: you send a
message, and two or three people say "yeah, you're right, that needs
to happen, make it so" without serious dissent
2.  No big omnibus whitespace cleanups.  These are of debatable use
any time, but now they make backporting a big pain-in-the-butt, and
we'll need to do a lot of backporting to 1.19.
3.  Have a reviewer lined up ready to ok your revision *before you
commit it*.  If you can't get a tentative commitment from a reviewer,
don't commit it.

We have a couple of different options in this interim period between
now and when we start using Git:
a.  we let people commit as was previously normal into trunk, but we
only migrate the code that's been formally reviewed.
b.  we insist on pre-commit review from now until we go live on Git.

So far, there hasn't been a lot of discussion on either option.  Brion
and Roan both pointed out problems with option "a", while no one has
raised a serious objection to option "b".

Rob
(Continue reading)

Permalink | Reply | 2 comments |
headers
lakmal padmakumara | 10 Feb 19:01
Picon

Common photo management plugins for MediaWiki

Hey Devs,

I'm Lakmal ,a final year undergraduate in University of Moratuwa ,Sri Lanka
who is interested about participating in GSoc 2012 summer programme with
WikiMedia Foundation . I already downloaded, and installed mediawiki and
hoping to start with some small
bugs<http://www.mediawiki.org/wiki/Annoying_little_bug>to make my self
familiar with the code base.

After going through the suggested idea list from the community ,I developed
a good interest in the above mentioned project where the final outcome
would be set of plugins for MediaWiki to communicate with common photo
management APIs ( Etc ,iPhoto ,Lightroom ..) .

I would be grateful if one of you can fill me up with the current status of
this project idea . In the sense I would like to know whether someone is
already working on this or this is sill open for an enthusiast to start
working on :) .

I believe this is the right mailing list to ask this question ,if not I
apologize and would expect someone to direct me to the correct place .

--

-- 
Thanks & Kind Regards

Lakmal Padmakumara
Undergraduate
Computer Science and Engineering Department
University of Moratuwa
Sri Lanka
(Continue reading)

Permalink | Reply | 4 comments |
headers
Aashish Mittal | 10 Feb 18:54
Picon
Gravatar

Regarding GSoC 2012

Hello everyone,

I am Aashish Mittal, a final year student from Mumbai University, India. I
aim to take part in GSoC 2012 with Mediawiki and wish to get an early start
in knowing and understanding the software well.

I am relatively new to the organizationg. I have been through the intro
steps <http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker> and
the project ideas of this year. I have started working on the code and
submitted a patch for one of the bugs (bug
33545<https://bugzilla.wikimedia.org/show_bug.cgi?id=33545>)
and am looking into solving more bugs.

I am going through the projects and the attached links. However, I would
request some more details on the following projects:

1. Integration of Mediawiki/Sakai: I have been a GSoC student with Sakai in
2010, so I would like to explore the project more deeper.

2. Convention extension for converting mediawiki wiki into website for
conference. I have been through the links, but I would like to get a better
technical understanding of this project related to the implementation of
the project. Any appropriate link or some useful guidelines would be great.

Apart from the above two projects, I am interested in a couple of more
projects (Create a way to have “books” for
wikisource/wikibooks<https://bugzilla.wikimedia.org/show_bug.cgi?id=15071>and
Give editors a way to slice
and dice their watchlists with
groups)<https://bugzilla.wikimedia.org/show_bug.cgi?id=5875>.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sumana Harihareswara | 10 Feb 18:53
Picon
Gravatar

MobileFrontend & John Du Hart's rewrite

John, Patrick, and anyone else who is interested in the MobileFrontend
extension:

John Du Hart is working on a rewrite, aiming to make it less Wikimedia
Foundation-centric, and there is disagreement regarding whether his
rewrite is desired.  Please read and comment:

https://www.mediawiki.org/wiki/Extension_talk:MobileFrontend#Issues_with_MobileFrontend_and_possible_rewrite_11940

(Can someone please forward this to mobile-l as well?  Thanks.)

--

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Permalink | Reply | 1 comment |
headers
Beebe, Mary J | 10 Feb 18:00
Picon
Favicon

Opening up an internal wiki - login maintenance without a mail server.

I have been working with internal wikis for a while.  We have several wikis that we edit within our company
then give the wiki to the client.  The client just searches the information and does not do any further edits.

We now have a wiki that we want to make external so I need to make sure I am addressing everything.

As far as user groups, I have it set that everyone can read the wiki and all login users can edit within the
wiki.  Only administrators can create a new user account.  We have provided an email address for people to
request authoring privileges.  The server we are using for the wiki does not have a mail server.   I am
assuming that we would need a mail server on the server to have the wiki email passwords to the person.  Is
that true or can we set it to use another mail server?

Thanks,

Mary Beebe
Battelle Charlottesville, VA
434-951-2149
This message is intended only for the use of the individual or entity to which it is addressed, and may
contain information that is privileged, confidential and/or otherwise exempt from disclosure under
applicable law. If the reader of this message is not the intended recipient or the employee or agent
responsible for delivering the message to the intended recipient, any disclosure, dissemination,
distribution, copying or other use of this communication or its substance is prohibited. If you have
received this communication in error, please return to the sender and delete from your computer system.
Permalink | Reply | 2 comments |
headers
Beebe, Mary J | 10 Feb 16:32
Picon
Favicon

Logging & messages

I was trying to use this old extension: http://www.mediawiki.org/wiki/Extension:UserLoginLog to log
login attempts.  It used $wgMessageCache; therefore it worked fine until we went to a 1.18 wiki.  I tried to
modernize it by creating a UserLoginLog.i18n file to keep the messages.

I have $wgExtensionMessagesFiles['userLoginLog'] = dirname( __FILE__ ) . "/UserLoginLog.i18n.php"; 
at setup.

A sample method is:

function wfUserLoginLogSuccess(&$user) {

        wfLoadExtensionMessages( 'userLoginLog' );

        $log = new LogPage('userlogin',false);

        $log->addEntry('success',$user->getUserPage(),wfGetIP());

        return true;

        }

The statement 'wfLoadExtensionMessages( 'userLoginLog' );' does not seem to do anything because the
message in the log is  <userlogin-success>  instead of the message.

I am not sure how to pass in the message log name or how to make it global now that wgmessageCache is no longer
available.  Is there a document on how to use the logging feature in the wiki?

Thanks,

Mary Beebe
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Du Hart | 10 Feb 05:08
Picon
Gravatar

Phabricator

Unless you've been living under a rock (If you have, how's the wifi under
there?) we're moving to git soon. Along with this will come a change in how
we do code review. However, some people have expressed concerns over the
usability of gerrit. Therefore I'd like to propose an alternative.

Phabricator is a code review tool written by and for Facebook that has
been open sourced. For an introduction, see this:
http://phabricator.com/docs/phabricator/article/Introduction.html

I've written up some documentation about Phabricator for our uses here:
https://www.mediawiki.org/wiki/Phabricator

I would really like for some of our developers and reviewers to try this
out as an alternative to gerrit. Personally I've found it much more
pleasurable to work with than gerrit. If we think this might be a viable
solution for us then I'd be willing to work on adding more integration
(LDAP support and Unit testing integration).

Let me know if you have any questions or feedback. Thanks!

--

-- 
John
Permalink | Reply | 4 comments |
headers
Jeroen De Dauw | 9 Feb 15:38
Picon
Gravatar

DBDataObject class

Hey all,

Over the last few extensions I've been creating I got annoyed at having to
create certain database interaction code over and over again and ended up
creating a DataObject class encapsulating most of the work and doing some
nice abstraction. The current version, as I have it in the Education
Program extension, is documented here:

https://www.mediawiki.org/wiki/User:Jeroen_De_Dauw/DBObject

An earlier version of this class which is included in the Contest extension
has been reviewed and is in use on mediawiki.org.

Since this is a very generic utility and is clearly useful in many
extensions (and probably in core as well), I like to put it into core for
MW 1.20. If you see issues that need to be resolved before this is done,
please describe them.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Permalink | Reply | 0 comments |
headers
Rob Lanphier | 8 Feb 21:17
Picon
Gravatar

How to avoid a post-branch code slush (Re: Branch 1.19 on Tuesday, February 6?)

On Wed, Feb 8, 2012 at 4:40 AM, Petr Bena <benapetr <at> gmail.com> wrote:
> Hi, is there any update on branching? Thank you

Sam will be doing it soon.

After that it means, in theory, that trunk will be open for
post-deploy commits.  However, we *cannot* let the same backlog back
up that we did before, and there's no way we can keep up with
everything we need to do for deployment (last minute bugfixes,
addressing fixmes regardless of committer) while at the same time
dealing with a flood of new commits.

A big problem with our current post-commit review regime is that it is
exactly these times that really regrettable changes can and probably
do get made.  Many refactoring exercises happen without much
discussion on the mailing list.  The code doesn't get reviewed, and
then it gets entangled with a lot of other important code to the point
that we're forced to forge ahead with a suboptimal refactoring
decision.  In addition to building up a large review backlog, we also
find ourselves chasing pockets of breakage due in part to incomplete
refactoring and backwards-incompatibility breakages.

We're migrating to Git very soon after this release.  It would really
suck to have a huge pile of unreviewed commits going into trunk.  So,
I'm going to suggest a Git migration strategy that will avoid having a
monsterous backlog.  Instead of cutting over trunk at the very latest
revision, we cut over at the latest revision that is fully reviewed
and ok.  Everything before the 1.19 branch point would be
grandfathered in, but everything after would need to be reviewed and
ok.  So, for example, if r111000 is the branch point, and
(Continue reading)

Permalink | Reply | 5 comments |
headers
Guillaume Paumier | 8 Feb 12:53
Picon
Gravatar

Wikimedia engineering report for January 2012

Hi,

The report covering Wikimedia engineering activities in January 2012
is now available.

Wiki version: https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2012/January
Blog version: https://blog.wikimedia.org/2012/02/08/engineering-january-2012-report/

--

-- 
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Permalink | Reply | 0 comments |

Gmane