Toolserver source control (was Re: Converting to Git?)

List overview All Threads
Download

newer

older

Review InterWiki Transclusion...

New gadget

Ryan Lane

22 Mar 2011 22 Mar '11

6:11 p.m.

...

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

Show replies by thread

Gerard Meijssen

22 Mar 22 Mar

6:23 p.m.

New subject: Toolserver source control (was Re: Converting to Git?)

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(a)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

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.

Ryan Lane

6:31 p.m.

New subject: Toolserver source control (was Re: Converting to Git?)

...

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.

Gerard Meijssen

6:51 p.m.

New subject: Toolserver source control (was Re: Converting to Git?)

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(a)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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

7:07 p.m.

New subject: Toolserver source control (was Re: Converting to Git?)

On Tue, Mar 22, 2011 at 1:51 PM, Gerard Meijssen <gerard.meijssen(a)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.

Roan Kattouw

7:22 p.m.

New subject: Toolserver source control (was Re: Converting to Git?)

2011/3/22 Gerard Meijssen <gerard.meijssen(a)gmail.com>om>:

...

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)

Mark Wonsil

7:29 p.m.

New subject: Toolserver source control (was Re: Converting to Git?)

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.

Krinkle

7:47 p.m.

New subject: Converting to Git?

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

Platonides

23 Mar 23 Mar

1:09 a.m.

New subject: Toolserver source control (was Re: Converting to Git?)

Mark Wonsil wrote:

...

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.

Marcin Cieslak

2:47 a.m.

New subject: Toolserver source control (was Re: Converting to Git?)

...

Mark Wonsil <wonsil(a)4m-ent.com> wrote:

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

Gerard Meijssen

5:23 a.m.

New subject: Toolserver source control (was Re: Converting to Git?)

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(a)4m-ent.com> wrote:

...

Gerard asks:

Does any of these communities have *daily updates* of its localisations

some 300 languages to its production environment? If so can you give references?

Ryan Lane

5:14 p.m.

New subject: Toolserver source control (was Re: Converting to Git?)

...

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

Diederik van Liere

6:51 p.m.

New subject: Converting to Git?

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(a)gmail.com> wrote:

...

On March 22 2011, at 20:29 Mark Wonsil wrote:

Another good read is http://whygitisbetterthanx.com/ -- Krinkle _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- <a href="http://about.me/diederik">Check out my about.me profile!</a>

4800

days inactive

4801

days old

wikitech-l@lists.wikimedia.org

Manage subscription

12 comments

9 participants

tags (0)

participants (9)

Diederik van Liere
Gerard Meijssen
Krinkle
Marcin Cieslak
Mark Wonsil
OQ
Platonides
Roan Kattouw
Ryan Lane