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 no real value.
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 LocalisationUpdate is such a production process. When the continuity of production processes is not a prime priority, something is fundamentally wrong.
You are misunderstanding. The thread isn't about toolserver, so you are muddying up a perfectly valid thread with something totally non-related.
Yes, toolserver has a problem, and it should be addressed. It isn't a problem with the MediaWiki developer community though, it's a problem with the toolserver community, and they need to fix it. But again, let's focus on one issue at a time.
- Ryan Lane
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. Thanks, GerardM
On 22 March 2011 19:11, Ryan Lane rlane32@gmail.com wrote:
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 no real value.
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 LocalisationUpdate is such a production process. When the continuity of production processes is not a prime priority, something is fundamentally wrong.
You are misunderstanding. The thread isn't about toolserver, so you are muddying up a perfectly valid thread with something totally non-related.
Yes, toolserver has a problem, and it should be addressed. It isn't a problem with the MediaWiki developer community though, it's a problem with the toolserver community, and they need to fix it. But again, let's focus on one issue at a time.
- Ryan Lane
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
Using git in toolserver doesn't help us use git for mediawiki development. It's a fairly different set of volunteers.
It's obvious git works. It's used by a number of fairly large communities. What we need to do is figure out the problems with using it in our community, and address them. Throwing a totally new problem into the mix won't help.
- Ryan Lane
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 rlane32@gmail.com wrote:
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.
Using git in toolserver doesn't help us use git for mediawiki development. It's a fairly different set of volunteers.
It's obvious git works. It's used by a number of fairly large communities. What we need to do is figure out the problems with using it in our community, and address them. Throwing a totally new problem into the mix won't help.
- Ryan Lane
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Mar 22, 2011 at 1:51 PM, Gerard Meijssen gerard.meijssen@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 number of languages nor frequency of updates have any bearing on the version control used once the infrastructure is in place.
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 Debian
Click on the links and see how long a directory has been idle, see a log of changes, and a nice summary of changes and by whom. For example, on the Android platform/SDK, you can click on http://android.git.kernel.org/?p=platform/sdk.git;a=summary and see all of the changes made in the last 24 hours. Clicking on http://android.git.kernel.org/?p=platform/sdk.git;a=log gives a detail listing of changes. Clicking further, you see the author and the reviewer who merged the original back into the production.
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 there's any doubt that git would work for Wikimedia but there would definitely be some workflow changes. That's probably the larger issue.
Mark W.
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 there's any doubt that git would work for Wikimedia but there would definitely be some workflow changes. That's probably the larger issue.
Mark W.
Another good read is http://whygitisbetterthanx.com/
-- Krinkle
The Python Community recently switched to a DVCS and they have documented their choice. It compares Git, Mercurial and Bzr and shows the pluses and minuses of each. In the end, they went for Mercurial.
Choosing a distributed VCS for the Python project: http://www.python.org/dev/peps/pep-0374/
best, Diederik
On Tue, Mar 22, 2011 at 3:47 PM, Krinkle krinklemail@gmail.com wrote:
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 there's any doubt that git would work for Wikimedia but there would definitely be some workflow changes. That's probably the larger issue.
Mark W.
Another good read is http://whygitisbetterthanx.com/
-- Krinkle
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 you to reorder them, but you would have as many commits or more (as it encourages doing many commits) than before. I prefer the 'many simple commits' approach, though.
Mark Wonsil wonsil@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 Mercurial, not git :)
Although I assume most of this thread is about using DVCS in general, and not only about git. Mercurial has a bit more concise and consistent set of commands.
//Marcin
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, GerardM
PS I described the work flow in quite some detail in another thread on the same subject.
On 22 March 2011 20:29, Mark Wonsil wonsil@4m-ent.com wrote:
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 Debian
Click on the links and see how long a directory has been idle, see a log of changes, and a nice summary of changes and by whom. For example, on the Android platform/SDK, you can click on http://android.git.kernel.org/?p=platform/sdk.git;a=summary and see all of the changes made in the last 24 hours. Clicking on http://android.git.kernel.org/?p=platform/sdk.git;a=log gives a detail listing of changes. Clicking further, you see the author and the reviewer who merged the original back into the production.
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 there's any doubt that git would work for Wikimedia but there would definitely be some workflow changes. That's probably the larger issue.
Mark W.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
I think we all get this. If we switch to git this will be addressed. If there's some specific technical concern you have, let us know.
- Ryan Lane
2011/3/22 Gerard Meijssen gerard.meijssen@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 an environment where our production will not get broken.
Like I said in the other thread, the notion that moving to Git will somehow break daily l10n updates is false.
As long as a VCS allows pushing changes to the repository on one machine and pulling those changes on another machine (and seriously, what kind of VCS can't do that), we can easily prevent essential production processes such as the incorporation of daily l10n updates and merging arbitrary changes to the deployment branch from getting broken. I therefore don't think we need to prove Git in a toolserver environment first, and support Chad's suggestion that we try it with phase3 first.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org