On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
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 people want to
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 pe
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
> wrote:
>> But actually the reason I
On Tue, Mar 22, 2011 at 08:27, Yuvi Panda wrote:
> On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
> 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 t
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 wa
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 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 best way for me to get
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 wrote:
> My development computer doesn't have an internet connection, it's not
> possible for me to wor
On 22 March 2011 11:54, Joseph Roberts 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 date.
- d.
_
On Tue, Mar 22, 2011 at 7:25 AM, Joseph Roberts
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 for me to be granted it
>
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 list
On Tue, Mar 22, 2011 at 8:23 AM, Joseph Roberts
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 send them here or submit
On 22 March 2011 12:30, Chad wrote:
> On Tue, Mar 22, 2011 at 8:23 AM, Joseph Roberts
> 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 :)
Heh, fair e
On Tue, Mar 22, 2011 at 10:33 PM, Joseph Roberts
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 version a while ago to
On Tue, Mar 22, 2011 at 9:07 AM, K. Peachey wrote:
> On Tue, Mar 22, 2011 at 10:33 PM, Joseph Roberts
> 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 Rob
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
multiple
On Tue, Mar 22, 2011 at 10:25 AM, Siebrand Mazeland
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 having
> this grea
2011/3/22 Chad :
> 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 400+
>
Extensions in SV
On Tue, Mar 22, 2011 at 10:44 AM, Roan Kattouw wrote:
> 2011/3/22 Chad :
>> 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 i18
2011/3/22 Chad :
> 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, let's not bite off
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 a
On Tue, Mar 22, 2011 at 11:08 AM, Trevor Parscal 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 u
On Tue, Mar 22, 2011 at 15:25, Siebrand Mazeland 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 having
> this great
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 reque
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
On Tue, Mar 22, 2011 at 16:33, Max Semenik 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 people can pull y
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
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 mailing list
Wikit
On 22-03-11 16:38 Trevor Parscal 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 work" instead of
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 co
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
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 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 warning recently - HTM
On Tue, Mar 22, 2011 at 12:11 PM, Siebrand Mazeland
wrote:
> On 22-03-11 16:38 Trevor Parscal 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 s
On Tue, Mar 22, 2011 at 9:11 AM, Siebrand Mazeland 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
> Subversion to Git? Only
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 feat
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 c
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 th
> 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 add
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.
Tha
> 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, Tod 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 provide search ca
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 wrote:
> > I brought two arguments, you do not address either. The issue is
> in
On Tue, Mar 22, 2011 at 1:51 PM, Gerard Meijssen
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 number of languages
2011/3/22 Gerard Meijssen :
> 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 daily process provided by
2011/3/22 Gerard Meijssen :
> 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 o
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 so
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 t
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] http://www.mediawiki.o
On Tue, Mar 22, 2011 at 1:42 PM, 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 (s
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 co
2011/3/22 Max Semenik :
> 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 fu
On Wed, Mar 23, 2011 at 2:25 AM, Max Semenik 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 warning recently - HTML
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 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 Selenium
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" wrote in message
news:aanlktikrre_3o+pycjdx2+qil6zt3tpohqucodwe_...@mail.gmail.com...
> On Tue, Mar 22, 2011 at 12:11 PM, Siebrand Mazeland
> wrote:
>
> Also, the
> comment about code review is also a point. Right now, CodeReview
> does not support Git, and really the implementation was
"K. Peachey" wrote in message
news:aanlktinanrjcoho_0rac4amfs3gt98hkr0nz2yzpk...@mail.gmail.com...
> On Wed, Mar 23, 2011 at 2:25 AM, Max Semenik
> wrote:
>> As the matter of fact, MediaWiki serves HTML5 by default. The only
>> reason why it is still not enabled on Wikipedia is backward
>> com
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 allo
On Tue, Mar 22, 2011 at 5:27 PM, Happy-melon 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 setting
> up a repla
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
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 fine with using HTML5 fe
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'
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 hav
>> 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.
The article is about Mercurial, no
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
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 an
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.
Thanks,
Στις 23-03-2011, ημέρα Τετ, και ώρα 02:03 +0100, ο/η Platonides έγραψε:
> 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
74 matches
Mail list logo