Hi all,
I am an undergraduate student, currently pursuing my Integrated degree( Msc. Chemistry and B.Tech Electronics& Instrumentation) from Bits Pilani(India). I am looking forward to apply for GSOC this year under Mediawiki. So from the list of projects/ideas stated on the Mediawiki gsoc page I wish to work on the idea of developing a convention extension which could be plugged into a wiki running the Mediawiki software.The current requirement states to have an extension which would help convert any wiki into a suitable website for conference ,such as Wikimania
Wikimania currently offers these many features :- - a separate main page is dedicated for listing the conference details - and features like registration, submission and talk (voting) are present - event management features - speaker descriptions -session details -schedule info -ticketing feature(payment gateway)
Wikimania is a site which is hand tailored for this purpose, so to get a better understanding of how such conference management software works i looked into a couple more available out there on the web such as OpenConferenceWare(Ruby on Rails)[1] and wisconDB(perl)[2]. So after having looked into the above listed packages and Wikimania I have come up with a list of tasks that should be performed by this extension :- 1. integration of new set of preferences in the preferences menu ( specially dedicated for the setting up of conference like features or even a separate menu page just to avoid the clutter) 2. creation of template pages for registration, submission and voting just like we already have in Wikimania but instead of creating them by hand this extension would create them for the admin. (this feature would work once the conference feature is enabled in the first step stated above) 3. creation of separate database tables which would solely handle this added functionality(just like wisconDB [2]) 4. creation of new templates(magic words) , that one could use in other pages as well (just to show some relevant information regarding the conference or event organized by the admin user) -an example of such a template already exists on Wikimania [3] Also had a discussion with ^demon on IRC regarding the approach that one should take for building such an extension, he threw me some more ideas that he had thought about this project and suggested me some more features such as :- 5. creation of special badges 6. export feature for all the user information which could be available in CSV or some other format I just wanted to provide an introduction to this project , that?s why may not have provided a detailed description of each point written above. So further information can be looked under this page https://meta.wikimedia.org/wiki/ConventionExtension< https://meta.wikimedia.org/wiki/Books%3E which i will be using for further development and plans on this project. Any sort of feedback would be appreciated.
Extra Info : [1] https://github.com/igal/openconferenceware [2] https://code.google.com/p/wiscondb/ [3] https://wikimania2012.wikimedia.org/wiki/Main_Page
Thanks, Akshay Chugh
On Fri, Feb 24, 2012 at 3:11 AM, wikitech-l-request@lists.wikimedia.orgwrote:
Send Wikitech-l mailing list submissions to wikitech-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikitech-l or, via email, send a message with subject or body 'help' to wikitech-l-request@lists.wikimedia.org
You can reach the person managing the list at wikitech-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Wikitech-l digest..."
Today's Topics:
- Re: Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 (Antoine Musso)
- Re: Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 (Trevor Parscal)
- Re: Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 (Arthur Richards)
- Re: Please Welcome Christian Aistleitner to Technical Operations (Ben Hartshorne)
- Re: Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 (Chad)
- Re: Please Welcome Christian Aistleitner to Technical Operations (Manuel Schneider)
- Re: Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 (Patrick Reilly)
- Re: Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 (Chad)
- Re: Caching of pages with time sensitive magic words (Platonides)
- Re: Git + Gerrit is a toughy (Antoine Musso)
Message: 1 Date: Thu, 23 Feb 2012 21:56:29 +0100 From: Antoine Musso hashar+wmf@free.fr To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 Message-ID: ji695p$dc8$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Le 21/02/12 16:08, Domas Mituzas wrote:
If MediaWiki is better on newer PHP, we should use newer PHP.
I have read that:
If MediaWiki is better on JS, we should use JS.
Go figure.
Message: 2 Date: Thu, 23 Feb 2012 13:02:07 -0800 From: Trevor Parscal tparscal@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 Message-ID: <CANKkVPpeT0CBmAgpxk+uzX3YXDyDnDhYR=Hhyqr3a=dEw4q77A@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Me too.
- Trevor
On Thu, Feb 23, 2012 at 12:56 PM, Antoine Musso hashar+wmf@free.fr wrote:
Le 21/02/12 16:08, Domas Mituzas wrote:
If MediaWiki is better on newer PHP, we should use newer PHP.
I have read that:
If MediaWiki is better on JS, we should use JS.
Go figure.
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<
https://lists.wikimedia.org/mailman/listinfo/wikitech-l%3E
Message: 3 Date: Thu, 23 Feb 2012 13:05:37 -0800 From: Arthur Richards arichards@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 Message-ID: <CAG5YvhLu-9Yzwf6d+y7dKNvpo0ay33A2iX2PM7K-X6jHbiG6bw@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
The correct answer is "I'm sorry this is inconvenient, ask your hosting provider or find a better one."
I completely agree.
Being able to use features like namespaces and late static binding would be a huge win. I'm definitely in favor of bumping the minimum PHP version to 5.3.x.
-- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687
Message: 4 Date: Thu, 23 Feb 2012 13:06:36 -0800 From: Ben Hartshorne bhartshorne@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Cc: wmfall@lists.wikimedia.org Subject: Re: [Wikitech-l] Please Welcome Christian Aistleitner to Technical Operations Message-ID: <CAF9NrhUO8-1TTjtU2d8G7aM+MEmOnh-3N+08-7iS6pdu=S5tJA@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Feb 23, 2012 at 9:56 AM, Ct Woo ctwoo@wikimedia.org wrote:
Hi All,
TechOps is happy to announce Christian Aistleitner has joined us as a consultant/contractor. Christian, who is based in Linz, Austria, will work towards hardening the XML dump infrastructure.
Though he just completed his PhD in 2011, he has been doing programming since his teenage years., and started working in 2001. His career
revolves
around free software integration, making software maintainable, and tracking down and fixing the ever hiding bugs.
He is a self-confessed code reading junkie, feeding on twisted,
I look forward to seeing some event-driven python programing! ;)
welcome.
-ben
Message: 5 Date: Thu, 23 Feb 2012 16:11:25 -0500 From: Chad innocentkiller@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 Message-ID: <CADn73rMOijzT-eYEkiNQHmRxm-0KAJK2EssvXYDtLBiod-qPnw@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 23, 2012 at 4:05 PM, Arthur Richards arichards@wikimedia.org wrote:
The correct answer is "I'm sorry this is inconvenient, ask your hosting provider or find a better one."
I completely agree.
Being able to use features like namespaces and late static binding would
be
a huge win. I'm definitely in favor of bumping the minimum PHP version to 5.3.x.
Namespaces are moderately useful. They would've been much nicer if PHP hadn't decided on completely batshit notation for them.
I'd also like to take a quick moment to put myself on the record as saying that I think LSB is a hack. It can has its uses, but the vast majority of examples I've seen in the wild so far are hacks to work around poor initial design decisions.
Please use features intelligently, not just because they're the shiny new tool in the drawer.
-Chad
Message: 6 Date: Thu, 23 Feb 2012 22:17:53 +0100 From: Manuel Schneider manuel.schneider@wikimedia.ch To: Wikimedia developers wikitech-l@lists.wikimedia.org Cc: wmfall@lists.wikimedia.org, Wikimedia ?sterreich vorstand@wikimedia.at Subject: Re: [Wikitech-l] Please Welcome Christian Aistleitner to Technical Operations Message-ID: 4F46AD01.6040303@wikimedia.ch Content-Type: text/plain; charset=iso-8859-1
Bonan tagon,
this time I may also chime in the "hello thread". Someone from Austria, great!
Is Christian already familiar with his favourite chapter, Wikimedia ?sterreich? I'd be happy to hear more from him...
/Manuel
Regards Manuel Schneider
Wikimedia CH - Verein zur F?rderung Freien Wissens Wikimedia CH - Association for the advancement of free knowledge www.wikimedia.ch
Message: 7 Date: Thu, 23 Feb 2012 21:19:03 +0000 From: Patrick Reilly preilly@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 Message-ID: <CAN211xnA-=Yg6K11DCDXRHLZHUmWwOTfY2gnQTz-+nG_vF9yxw@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
The key features of PHP 5.3.0 include:
Support for namespaces Late static binding Lambda Functions and Closures
Syntax additions: NOWDOC, ternary short cut "?:" and jump label (limited goto), __callStatic() Under the hood performance improvements Optional garbage collection for cyclic references
More consistent float rounding...
Deprecation notices are now handled via E_DEPRECATED (part of E_ALL) instead of the E_STRICT error level
Several enhancements to enable more flexiblity in php.ini (and ini parsing in general)
On Feb 24, 2012 2:35 AM, "Arthur Richards" arichards@wikimedia.org wrote:
The correct answer is "I'm sorry this is inconvenient, ask your hosting provider or find a better one."
I completely agree.
Being able to use features like namespaces and late static binding would
be
a huge win. I'm definitely in favor of bumping the minimum PHP version to 5.3.x.
-- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Message: 8 Date: Thu, 23 Feb 2012 16:23:38 -0500 From: Chad innocentkiller@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Bump of minimum required PHP version to 5.3 for MediaWiki 1.20 Message-ID: <CADn73rOFOycx4sSmdDvOos70rEh8F07ipyaQpKCYMkSMeC4g6g@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 23, 2012 at 4:19 PM, Patrick Reilly preilly@wikimedia.org wrote:
Syntax additions: NOWDOC,
This is actually very useful.
ternary short cut "?:"
I don't think this syntax is all that intuitive. People are lazy though, so I guess it'll get used.
and jump label (limited goto), __callStatic()
If anyone uses jump I'm going to whack them over the head with a revert stick. I see zero reason why this should ever be needed.
Under the hood performance improvements Optional garbage collection for cyclic references
This is my favorite part of 5.3 <3
-Chad
Message: 9 Date: Thu, 23 Feb 2012 22:38:12 +0100 From: Platonides Platonides@gmail.com To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Caching of pages with time sensitive magic words Message-ID: ji6bav$vqg$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1
On 23/02/12 17:55, Sezgin Sucu wrote:
Hi I am curious as to how mediawiki sites are dealing with caching of pages that contain time sensitive magic words that change from time to time. e.g. CURRENTTIME.
Does mediawiki software send a different expiration time for such pages? I have tested myself and haven't seen a difference.
Thanks
The parser cache expires much earlier in that case. Although we don't reduce it to lower than one hour due to the presence of such words.
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/MagicWord.ph...
Message: 10 Date: Thu, 23 Feb 2012 22:43:41 +0100 From: Antoine Musso hashar+wmf@free.fr To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Git + Gerrit is a toughy Message-ID: ji6bua$4t3$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Le 21/02/12 18:44, Andrew Otto a ?crit :
[~/Projects/wm/analytics/reportcard] (master)[29c6b47]$ git-review You have more than one commit that you are about to submit. The outstanding commits are:
29c6b47 (HEAD, master) observation.py - comments 14a771a test commit for git branch push 73dd606 Buncha mini changes + hackiness to parse a few things. This
really needs more work
2d37c13 pipeline/user_agent.py - adding comment that this file should
not be used
5892eb8 Adding loader.py - first hacky loader, just so we can get some
data into mysql to work with.
e3fb30b Renaming the concept of variables to 'traits'. Allowing
trait_sets to be specified so that we don't record HUGE amounts of data.
d0de74b base.py - adding schema in comments. Got lots of work to do to
make this prettier
328e55d Trying my darndest to clean things up here! I've cloned a new
repo, and am checking in my non-committed (an non-approved?) changes into this new branch. Hopefully gerrit will be happier with me.
This smells of me doing something really wrong.
It seems to be a git-review safe guard to prevents someone from sending several commits. Each of them would make Gerrit generates several changes. To those wondering why one would have multiple commits, three use cases come to mind.
I will give you the solution at the end of this post.
- high frequency tradin^H^H^H^H^H^H committing
Some people, me for example, do local commits very often, then squashes them before submitting the final patch. Git squashing means regrouping multiples commits in just one. Imagine I have made 4 commits locally, possibly using my mother tongue (french), in such case, using git-review will have me submitting a commit list like:
abcde1 oh mygod d30909 variable fun f39004 je ne sais plus ce que c'est 439090 before lunch
f39004 is some French meaning "I don't remember what was that" which does not describe the commit change (hint: using French will be perfectly valid once we start migrating from English).
Anyway, git-review would generates 4 changes out of the 4 commits above. Not that helpful is it?
Instead I would have wanted to regroup them and write a nice commit description. For example:
30490 (bug 1234) fix issue in feature foobar
- newbie spamming gerrit
This happen when you first play with Gerrit.
In subversion world, whenever you submit a new patch (svn commit) it is going to be written down in the central repository. You will not be able to change it, hence any subsequent submission based on it are guaranteed it is not going to change.
In git world, as I understand it, each commit as a parent commit. The reference is a sha1 based on the content of the commit. Whenever you change a commit, every children, grand-children .. will have their sha1 recomputed.
Enter in Gerrit world, when we send a commit in a queue, there is no guarantee that commit will end up in the reference repo. It might be amended or simply rejected. So your list of commit will be recomputed and all child / grand children will need to be resubmitted.
Guess that? That will update of all those Gerrit changes, making mass email spam / jenkins rebuild etc.
- mixing features
You could well be mixing two different changes. Maybe you have made a commit to fix bug 1234 and two days later a fix for bug 6789. Those should really be two different changes.
In conclusion, it is best to use a local branch for any bug / feature you might be working on actually. Branches are cheap in git, they are just a pointer. Once you are happy with your small branch, squash the commits and submit the end result. Less changes, less spam.
If you really want to *spam* force git-review to do it with a yes card:
$ git-review --yes
But you probably want to use branch / squash instead.
:-)
-- Antoine "hashar" Musso Migration to French is not scheduled yet
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 103, Issue 62