On 19/03/11 00:09, Rob Lanphier wrote:
Hi everyone,
Russ Nelson (svn account: nelson) is a new committer to core
MediaWiki. Russ is contracting to Wikimedia Foundation to create a
scalable media storage system based on OpenStack's Swift object store,
some Swift middleware custom for
On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
But actually the reason I did this mirror was as a proof of concept
for a (still incomplete) conversion to Git.
Is there still interest in that? I don't have a lot of time for it,
but I could help with that if
On 3/18/11 9:22 PM, Daniel Friesen wrote:
Take a look at riak too. Wikia's sysadmin Artur (crucially) built file
storage for Wikia using riak and a custom fuse module.
This is way past the planning stages -- Russell has been working on this
since late last year, along with a handful of WMF
I was waiting for RobLa to jump in here... as far as I know we are still
trying to find ways to move to Git, Some time after the dust settles on
1.17.
Rob?
On 3/22/11 12:27 AM, Yuvi Panda wrote:
On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
But actually
On 11-03-22 01:22 AM, Neil Kandalgaonkar wrote:
[...]
Also I wonder why not go directly from a MediaWiki FileRepo using REST
calls straight into Riak. That's more or less what Russell is building
for us except the backend will be Swift.
[...]
I actually asked Artur about that myself, I was
Hi Benedict,
one way to make tests more structured and easier to maintain would be to
provide a standard set of operations within the Selenium Framework. A list of
suggestions can already be found at
http://www.mediawiki.org/wiki/SeleniumFramework#Notes_and_further_improvements.
However, this
I have been wondering, I am unable to access SVN at all.
What would be the best way for me to get the code and submit patches?
Also, I am assuming that access to the repo would be completely
useless to me; would there be no reason for me to be granted it
therefore or would it still have its uses?
On 22/03/11 22:25, Joseph Roberts wrote:
I have been wondering, I am unable to access SVN at all.
What would be the best way for me to get the code and submit patches?
I think we should probably start with you telling us why you can't
access Subversion, and us trying to think of ways to fix it
My development computer doesn't have an internet connection, it's not
possible for me to work around that.
On 22 March 2011 11:29, Tim Starling tstarl...@wikimedia.org wrote:
On 22/03/11 22:25, Joseph Roberts wrote:
I have been wondering, I am unable to access SVN at all.
What would be the
Adding to that, the only computer I have that can access the internet
I have no control over. I basically copy of IE and that i it.
TIA - Joseph Roberts
On 22 March 2011 11:31, Joseph Roberts roberts.jos...@ntlworld.com wrote:
My development computer doesn't have an internet connection, it's
On 22 March 2011 11:54, Joseph Roberts roberts.jos...@ntlworld.com wrote:
Adding to that, the only computer I have that can access the internet
I have no control over. I basically copy of IE and that i it.
Nightly dumps: http://toolserver.org/~vvv/mw-nightly/
These appear to be kept up to
On Tue, Mar 22, 2011 at 7:25 AM, Joseph Roberts
roberts.jos...@ntlworld.com wrote:
What would be the best way for me to get the code and submit patches?
Upload your patches to Bugzilla.
Also, I am assuming that access to the repo would be completely
useless to me; would there be no reason
I was not aware of the nightly dumps. Thanks much!
What does it mean by phase3, out of interest?
For non bugged patches, should I send them here or submit a bug to
Bugzilla for the sake of completeness?
TIA - Joseph Roberts
___
Wikitech-l mailing
On Tue, Mar 22, 2011 at 8:23 AM, Joseph Roberts
roberts.jos...@ntlworld.com wrote:
I was not aware of the nightly dumps. Thanks much!
What does it mean by phase3, out of interest?
It was the third phase of the Wikipedia software, just never
been renamed :)
For non bugged patches, should I
On 22 March 2011 12:30, Chad innocentkil...@gmail.com wrote:
On Tue, Mar 22, 2011 at 8:23 AM, Joseph Roberts
roberts.jos...@ntlworld.com wrote:
I was not aware of the nightly dumps. Thanks much!
What does it mean by phase3, out of interest?
It was the third phase of the Wikipedia software,
On Tue, Mar 22, 2011 at 10:33 PM, Joseph Roberts
roberts.jos...@ntlworld.com wrote:
Thanks all, I'm hoping I can offer many things to the projects.
Another thing, is the latest version of XAMPP for Windows sufficient
for developing on?
TIA - Joseph Roberts
Yes, they finally updated the php
On Tue, Mar 22, 2011 at 9:07 AM, K. Peachey p858sn...@yahoo.com.au wrote:
On Tue, Mar 22, 2011 at 10:33 PM, Joseph Roberts
roberts.jos...@ntlworld.com wrote:
Thanks all, I'm hoping I can offer many things to the projects.
Another thing, is the latest version of XAMPP for Windows sufficient
From what I understand, common thought is that phase3 and all individual
extensions, as well as directories in trunk/ aside from extensions and
phase3 will be their own repos. Possibly there will be meta collections
that allow cloning things in one go, but that does not allow committing to
On Tue, Mar 22, 2011 at 10:25 AM, Siebrand Mazeland
s.mazel...@xs4all.nl wrote:
Please convince me that things will not be as hard as I describe above, or
will most definitely not turn out as I fear. I am open to improvements,
but moving to GIT without addressing these concerns for the sake of
2011/3/22 Chad innocentkil...@gmail.com:
I've actually come to partially agree with you since the last time we
discussed this. Really, the extension repository *should* remain in
Subversion as it is. I would, however, like to move phase3 to git.
Then i18n can just be two commits, instead of
On Tue, Mar 22, 2011 at 10:44 AM, Roan Kattouw roan.katt...@gmail.com wrote:
2011/3/22 Chad innocentkil...@gmail.com:
I've actually come to partially agree with you since the last time we
discussed this. Really, the extension repository *should* remain in
Subversion as it is. I would, however,
2011/3/22 Chad innocentkil...@gmail.com:
Perhaps in the long run. I think in the short-run it'd be more pain-free
and perhaps a useful experiment to just move phase3 to git. Then we
can see how we feel about moving the rest over (or if we hate it and
want to go back)
Hmm, that's a good point,
Your objections seem to be based on the assumption that you would need to have
push access to all repositories, but I think that's the point of DCVS, you can
just fork them, and then people can pull your changes in themselves (or using a
tool). Pull requests could even be generated when things
On Tue, Mar 22, 2011 at 11:08 AM, Trevor Parscal tpars...@wikimedia.org wrote:
Your objections seem to be based on the assumption that you would need to
have push access to all repositories, but I think that's the point of DCVS,
you can just fork them, and then people can pull your changes in
On Tue, Mar 22, 2011 at 15:25, Siebrand Mazeland s.mazel...@xs4all.nl wrote:
Please convince me that things will not be as hard as I describe above, or
will most definitely not turn out as I fear. I am open to improvements,
but moving to GIT without addressing these concerns for the sake of
On 22.03.2011, 18:08 Trevor wrote:
Your objections seem to be based on the assumption that you would
need to have push access to all repositories, but I think that's the
point of DCVS, you can just fork them, and then people can pull your
changes in themselves (or using a tool). Pull requests
My suggestion is that all of this busy work is highly automatable, but I'm
sure he has a greater ability to assess the complexities of this work than I do.
In general I feel that we should be thinking about how would we make this
work instead of why should we not do this.
- Trevor
On Mar 22,
On Tue, Mar 22, 2011 at 16:33, Max Semenik maxsem.w...@gmail.com wrote:
On 22.03.2011, 18:08 Trevor wrote:
Your objections seem to be based on the assumption that you would
need to have push access to all repositories, but I think that's the
point of DCVS, you can just fork them, and then
Hello!
What is the current concensus on HTML5?
Are we going to fully support it and use as many features as we can or
are we going to keep just using javascript alterntives?
I would assume that we would continue to use javascript in the case
that the client does not support HTML5, though that may
On Wed, Mar 23, 2011 at 2:00 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
I think you're missing the point that there's no reason why 400
commits should be harder than 1 in this case.
Code review comes to mind there.
-Peachey
___
Wikitech-l
On 22-03-11 16:38 Trevor Parscal tpars...@wikimedia.org wrote:
My suggestion is that all of this busy work is highly automatable, but
I'm sure he has a greater ability to assess the complexities of this work
than I do.
In general I feel that we should be thinking about how would we make
this
Hoi,
When you look at the situation with the Toolserver where everybody has its
own toy source area you have a situation where internationalisation and the
upgrading of functionality to a production level is not happening. If GIT is
so great, then solve an existing pain which is the inability to
Joseph Roberts wrote:
Hello!
What is the current concensus on HTML5?
Are we going to fully support it and use as many features as we can or
are we going to keep just using javascript alterntives?
I would assume that we would continue to use javascript in the case
that the client does not
On 22.03.2011, 19:05 Joseph wrote:
Hello!
What is the current concensus on HTML5?
Are we going to fully support it and use as many features as we can or
are we going to keep just using javascript alterntives?
I would assume that we would continue to use javascript in the case
that the
When you look at the situation with the Toolserver where everybody has its
own toy source area you have a situation where internationalisation and the
upgrading of functionality to a production level is not happening. If GIT is
so great, then solve an existing pain which is the inability to
On Tue, Mar 22, 2011 at 12:25 PM, Max Semenik maxsem.w...@gmail.com wrote:
As the matter of fact, MediaWiki serves HTML5 by default. The only
reason why it is still not enabled on Wikipedia is backward
compatibility with numerous screen-scraping scripts/tools. However,
they had their last
On Tue, Mar 22, 2011 at 12:11 PM, Siebrand Mazeland
s.mazel...@xs4all.nl wrote:
On 22-03-11 16:38 Trevor Parscal tpars...@wikimedia.org wrote:
My suggestion is that all of this busy work is highly automatable, but
I'm sure he has a greater ability to assess the complexities of this work
than I
On Tue, Mar 22, 2011 at 9:11 AM, Siebrand Mazeland s.mazel...@xs4all.nl wrote:
IMO that a bridge too far. My question is Why should we make this
happen?, and more specifically, what do our various stakeholders (which
groups?) gain or lose in case MediaWiki development would shift from
Hello,
Some localizable messages in MediaWiki features and extensions have
very complicated, ambiguous and error-prone wording. A big example for
that would be FlaggedRevs, but there are others. MediaWiki also has
ability for changing messages according to number, gender and other
grammatical
Hoi,
We are indeed using SVN successfully.
As to Toolserver, this environment and its functionality is deeply flawed.
As the tools are open source, there is no reason why relevant tools cannot
be brought into GIT and upgraded to a level where they are of production
quality. Either GIT is able to
On Mar 22, 2011, at 1:32 PM, Amir E. Aharoni wrote:
1. Are there currently any tests in the MediaWiki test suite that
focus on localization?
The MediaWiki PHPUnit test suites are still very much incomplete, and have yet
to test a fraction of the MediaWiki code. That said, there are tests
As to Toolserver, this environment and its functionality is deeply flawed.
As the tools are open source, there is no reason why relevant tools cannot
be brought into GIT and upgraded to a level where they are of production
quality. Either GIT is able to cope or its distributed character adds
Hoi,
I brought two arguments, you do not address either. The issue is introducing
GIT, there are production processes that will break. Not addressing this and
not proving that it can provide the goods is at issue. I suggest proving GIT
in an environment where our production will not get broken.
I brought two arguments, you do not address either. The issue is introducing
GIT, there are production processes that will break. Not addressing this and
not proving that it can provide the goods is at issue. I suggest proving GIT
in an environment where our production will not get broken.
On 03/21/2011 2:36 PM, Marco Schuster wrote:
Hi,
On Mon, Mar 21, 2011 at 3:49 PM, Todlistac...@gmail.com wrote:
Is this possible? Is the wiki search driven by a crawler that would
follow the links on that new wiki home page? If not, is there an
approach I could follow to be able to
Hoi,
Does any of these communities have *daily updates* of its localisations in
some 300 languages to its production environment? If so can you give
references?
Thanks,
GerardM
On 22 March 2011 19:31, Ryan Lane rlan...@gmail.com wrote:
I brought two arguments, you do not address either.
On Tue, Mar 22, 2011 at 1:51 PM, Gerard Meijssen
gerard.meijs...@gmail.com wrote:
Hoi,
Does any of these communities have *daily updates* of its localisations in
some 300 languages to its production environment? If so can you give
references?
Thanks,
GerardM
I dont see how neither the
2011/3/22 Gerard Meijssen gerard.meijs...@gmail.com:
The notion that it has to be MediaWiki core and or its extensions first is
absurd when you consider that it is what we use to run one of the biggest
websites of the world. We rely on the continued support for our production
process. The
2011/3/22 Gerard Meijssen gerard.meijs...@gmail.com:
Hoi,
I brought two arguments, you do not address either. The issue is introducing
GIT, there are production processes that will break. Not addressing this and
not proving that it can provide the goods is at issue. I suggest proving GIT
in
I've started collecting some notes on issues that need to be considered for
a potential git migration:
http://www.mediawiki.org/wiki/Git_migration_issues
I'm paying particular attention to the localization workflow thing. Note
that TranslateWiki's been working on StatusNet's git repository for
Gerard asks:
Does any of these communities have *daily updates* of its localisations in
some 300 languages to its production environment? If so can you give
references?
You can go to http://git-scm.com/ and see git projects for:
Linux Kernel
Perl
Eclipse
KDE
Ruby on Rails
Android
PostgreSQL
On March 22 2011, at 20:29 Mark Wonsil wrote:
I haven't used git yet but after reading the excellent article that
Rob Lanphier posted (http://hginit.com/00.html), I think I will. That
article also explains why there wouldn't have to be as many updates to
SVN as is done today.
I don't think
To reduce the amount of clicks needed during code review, I wrote a
gadget that displays basic information about a revision in
tooltips.[1] To enable it, you need to check Display revision
information in tooltips in your preferences (section Gadgets).
Have fun!
[1]
On Tue, Mar 22, 2011 at 1:42 PM, Max Semenik maxsem.w...@gmail.com wrote:
To reduce the amount of clicks needed during code review, I wrote a
gadget that displays basic information about a revision in
tooltips.[1] To enable it, you need to check Display revision
information in tooltips in
Hello,
The right way to do it is to have a test suite: A document that walks
the translator through all the use cases of the feature so that all
possible messages permutations and combinations appear.
Possibly, Selenium tests could be helpful. A Selenium test basically acts as a
remote
2011/3/22 Max Semenik maxsem.w...@gmail.com:
To reduce the amount of clicks needed during code review, I wrote a
gadget that displays basic information about a revision in
tooltips.[1] To enable it, you need to check Display revision
information in tooltips in your preferences (section
On Wed, Mar 23, 2011 at 2:25 AM, Max Semenik maxsem.w...@gmail.com wrote:
As the matter of fact, MediaWiki serves HTML5 by default. The only
reason why it is still not enabled on Wikipedia is backward
compatibility with numerous screen-scraping scripts/tools. However,
they had their last
On 22/03/11 21:42, Max Semenik wrote:
To reduce the amount of clicks needed during code review, I wrote a
gadget that displays basic information about a revision in
tooltips.[1] To enable it, you need to check Display revision
information in tooltips in your preferences (section Gadgets).
Markus Glaser gla...@hallowelt.biz wrote:
Hello,
The right way to do it is to have a test suite: A document that walks
the translator through all the use cases of the feature so that all
possible messages permutations and combinations appear.
Possibly, Selenium tests could be helpful. A
Roan Kattouw wrote:
The only thing that may be different, depending on what our workflow
ends up being, is that messages that have been added in some branch
that hasn't been merged to trunk yet will not automatically be picked
up by TWN for translation. This is technically already the case,
Chad innocentkil...@gmail.com wrote in message
news:aanlktikrre_3o+pycjdx2+qil6zt3tpohqucodwe_...@mail.gmail.com...
On Tue, Mar 22, 2011 at 12:11 PM, Siebrand Mazeland
s.mazel...@xs4all.nl wrote:
Also, the
comment about code review is also a point. Right now, CodeReview
does not support
K. Peachey p858sn...@yahoo.com.au wrote in message
news:aanlktinanrjcoho_0rac4amfs3gt98hkr0nz2yzpk...@mail.gmail.com...
On Wed, Mar 23, 2011 at 2:25 AM, Max Semenik maxsem.w...@gmail.com
wrote:
As the matter of fact, MediaWiki serves HTML5 by default. The only
reason why it is still not
Marcin Cieslak wrote:
So having a possibility to have a pre-flight test of the translation
(or even watch the demo of the original in action) is something
Selenium could deinitely help. In many cases, translators
do not have permission to experience some interface in the live
environment
Mark Wonsil wrote:
I haven't used git yet but after reading the excellent article that
Rob Lanphier posted (http://hginit.com/00.html), I think I will. That
article also explains why there wouldn't have to be as many updates to
SVN as is done today.
I don't see that conclusion. A DCVS allows
On Tue, Mar 22, 2011 at 5:27 PM, Happy-melon happy-me...@live.com wrote:
To my mind, this is one of the most important points. We have built up a
very comprehensive infrastructure for code review in SVN, and there is a lot
of manhours behind that work; and just as many hours associated with
I really need to sort out how I receive mailing list, rather than just
digests
Just tested it, literally copy pasting the gadget into one of the existing
CR JS files (granted, if/when committed it should be its own file), refresh
CR, and it works.
Should be easy to put in our SVN, no? ;)
On Tue, Mar 22, 2011 at 12:05 PM, Joseph Roberts
roberts.jos...@ntlworld.com wrote:
What is the current concensus on HTML5?
http://www.mediawiki.org/wiki/HTML5
Are we going to fully support it and use as many features as we can or
are we going to keep just using javascript alterntives?
We're
On 22/03/11 20:26, Brion Vibber wrote:
I've started collecting some notes on issues that need to be considered for
a potential git migration:
http://www.mediawiki.org/wiki/Git_migration_issues
I'm paying particular attention to the localization workflow thing. Note
that TranslateWiki's been
On 23/03/11 04:24, Rob Lanphier wrote:
The most convincing general Subversion-DVCS argument I've read is here:
http://hginit.com/00.html
This argument refers to Mercurial, but the same benefits apply to Git.
The article seems quite biased.
Here’s the part where you’re just going to have to
Mark Wonsil won...@4m-ent.com wrote:
I haven't used git yet but after reading the excellent article that
Rob Lanphier posted (http://hginit.com/00.html), I think I will. That
article also explains why there wouldn't have to be as many updates to
SVN as is done today.
The article is about
On 23/03/11 12:05, Rob Lanphier wrote:
If our code review system was working smoothly, I wouldn't mind
delaying this. However, it's pretty clear that code reviews aren't
keeping pace (be sure to look at revisions marked new in trunk):
http://toolserver.org/~robla/crstats/crstats.trunkall.html
Hoi,
From the point of view of the internationalisation and localisation there
are two states.
- the English message is stable and fits the requirements of i18n; it is
a meaningful translatable message with constructs like gender and plural as
needed
- The English message is stable
Hoi,
All these projects do not update their localisation to live environments on
a daily basis including environments on a previous release. The localisation
for these projects is very much part of a release strategy and this is not
the practice we have in place for MediaWiki installations.
73 matches
Mail list logo
