Hi folks,
this is a great evening, as Wikidata began to work after the Wikibase
client was deployed on Hungarian
Wikipedia<http://hu.wikipedia.org/w/index.php?title=Triatlon&diff=prev&oldid=12906358>two
hours ago.
See this blog, too:
http://blog.wikimedia.de/2013/01/14/first-steps-of-wikidata-in-the-hungaria…
Then people came from all over the world and began to remove interwikis
happily to see the greatness of Wikidata and the bots began to put them
back.
See
http://hu.wikipedia.org/w/index.php?title=H%C3%A1ss%C3%A1gy&action=historyf…
example.
So the whole removement movement was ceased because it is senseless this
way.
So would somebody teach interwiki.py not to restore removed interwikis to
Hungarian Wikipedia? We have Wikidata, thanks. :-)
However, bots should not leave huwiki alone completely, as {{link FA}} and
{{link GA}} is not in the scope of Wikidata at the moment (it will be added
later), so this is still the task of bots.
After you tell us that interwiki.py is ready, we give some time for bots
being updated, and afterwards bots using old code may be blocked. We would
like to enjoy removing interwikis. :-)
FYI: next Wikipedias to test Wikidata will be Hebrew and Italian in a few
weeks. They will be followed by English if tests are successful, then the
others.
--
Bináris
Hi,
What's the preferred way to send patches to the Pywikipedia framework?
Is it through this mailing list or through the bug tracker in SF?
David E. Narváez
Dear all
I have posted to this mailing list in January with a library that I
wanted to contribute to the codebase. This is part of an effort on my
side to refactor code that accumulated over various bot-operator tasks
and make it available to the community. The main part of the code
deals with spellchecking using hunspell
(http://hunspell.sourceforge.net/) instead of the list-based approach
currently used in spellcheck.py. The second part is an interactive
robot to do revision control (Sichten) in the german wikipedia. There
are some api functions that use the "undo" functions of the
action=edit command and an api function that uses the action=review
command.
So I wanted to ask whether somebody had time to have a look at the
code I submitted here
http://sourceforge.net/tracker/?func=detail&aid=3479070&group_id=93107&atid…
(I uploaded a new file "(moved testSamples)" please us this to test,
the other one seems corrupt and cannot be deleted any more as well).
Thus, is there a code-review process that I can undergo or what do you
suggest is the best way to get the code into trunk (if at all?). Would
it be easier if I talked directly to one of you?
What are the criteria to get SVN commit access -- I was just wondering
what the general rules are.
Greetings
Hannes
Hello all,
As you might know, the Wikimedia Foundation (WMF) has moved most
Mediawiki (MW)-related repositories from svn version control to git +
gerrit. As a consequence, the WMF also wants to stop running their svn
server - which is the server we are using.
Now the question is: where do we want to move to, and what version
control system (vcs) do we want to use? Do we find that the WMF
gerrit-based system is user-friendly and easy enough? Do we care about
having svn-based access?
I think there are a few options we can consider:
1) go with the gerrit flow: convert the repository to git and host the
repositories with the WMF. This has the advantage of having the
repository in a practical place (with all the other MW related
repositories).
2) move to github: convert to git, and host the repository at github.
This has the advantage of the user-friendlyness of github, but also
gives us SVN access. We can always easily move to WMF-based hosting
once we feel it is user-friendly enough: the github repository will
then just mirror the WM=F-hosted repository.
3) move to another SVN host. This is easier (we don't need to convert
any repository), but it also means that it will be hard to move to
WMF-based hosting when we want. In addition, we don't get the nice
things git gives us: easy branching and easy patch submission ('pull
requests').
Personally, I am in favor of option (2): gerrit is clearly useful for
managing a project of the size of MW, but I think it is probably
overkill for something the size of pywikipedia. Github has an (imo)
much clearer interface than gerrit, and has tons of information for
new git users. Last, but not least, github has svn support, which
makes it even easier to switch, for both contributors and users.
I welcome your opinions!
Merlijn
For me splitting the repository depends on how to proceed the checkout of all new repositories and externals. At the moment I have 4 repositories for developing (2 trunk 2 rewrite) and two (1/1) for committing approved changes and two (1/1) on a different machine for running the bot in autonomous mode. I do not like virual environment for developing, i didn't get it working in past.
I would prefer splitting the framework trunk and rewrite and perhaps in next future a new py3.0 framework based on the rewrite branch. Next I would split i18n from these framework forks as they must be the same; now trunk use it as external from rewrite. In a same way the family files could be separated when the framework is able to handle remaining different setting (e.g. namespaces, ssl etc.)
Also I have the idea to split scripts from the framework and enable running the same script with different frameworks (look at noreferences.py: only the imports are different). This means most bots must become a library and all interfaces must be the same, independent from py release and api/screen scrapping modules.
Happy new year
xqt
----- Original Nachricht ----
Von: Merlijn van Deen <valhallasw(a)arctus.nl>
An: Pywikipedia discussion list <pywikipedia-l(a)lists.wikimedia.org>, yuriastrakhan(a)gmail.com
Datum: 27.12.2012 20:09
Betreff: Re: [Pywikipedia-l] git migration: repository structure
> On IRC, I had a quick chat with Yuri on this issue. A few pointers
> from the discussion - (I hope I worded your points correctly, Yuri -
> if not, please correct me!)
>
> On 27 December 2012 16:00, Merlijn van Deen <valhallasw(a)arctus.nl> wrote:
> > In our repository, we have the following projects:
> > - pywikiparser
> > - threadedhttp
> > - pywikipedia
>
> pywikiparser should certainly be split, but threadedhttp might warrant
> some discussion:
>
> > and I think we should also split off the third party libraries - and
> > maybe remove them altogether. It might make sense to package them in
> > the nightlies, though.
>
> Basically, the question boils down to whether we want a 'pure'
> repository (which is harder to install, especially on windows), or a
> repository where third-party libraries (which sort-of includes
> threadedhttp - it doesn't need pywikipedia to function) are included.
>
> I'm inclined to say we should have an easy-to install bundle for
> windows users and developers (e.g. using PyInstaller), and have
> something virtualenv- and pip-based (or just installed packages) for
> linux users, but Yuri is a proponent of bundling everything in the
> repository.
>
> > - split off family files
> > - split off userinterfaces (?)
>
> Yuri thinks, and I am inclined to agree, that we should not split
> these - they really are part of the core framework, and cannot easily
> be used outside of it.
>
> One last thing we could not really agree on is how big the 'user, not
> developer'-market is: how many people are using the bots, but are not
> programmers (and thus do not write/improve the bots)?
>
> Merlijn
>
> _______________________________________________
> Pywikipedia-l mailing list
> Pywikipedia-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
>