On Fri, Mar 25, 2011 at 2:12 AM, Aryeh Gregor
simetrical+wikil...@gmail.com wrote:
I don't think moving to git will make code review very much easier in
the short term. It would probably disrupt code review considerably,
in fact, because people would have to get used to the new system. So
I
Aryeh Gregor wrote:
My experience with Mercurial is that if you type the wrong commands,
it likes to destroy data. For instance, when doing an hg up with
conflicts once, it opened up some kind of three-way diff in vim that I
had no idea how to use, and so I exited. This resulted in my
On 24/03/11 06:47, MZMcBride wrote:
It's only impolite if you criticize the code review tool without being
constructive. What specifically do you not like about the current code
review tool? And have you filed bugs about getting these issues addressed?
I have answered to this message in a new
On Tue, Mar 22, 2011 at 10:46 PM, Tim Starling tstarl...@wikimedia.org wrote:
The tone is quite different to one of the first things I read about
Mercurial:
Oops! Mercurial cut off your arm!
Don't randomly try stuff to see if it'll magically fix it. Remember
what you stand to lose, and set
On 11-03-24 06:12 PM, Aryeh Gregor wrote:
On Tue, Mar 22, 2011 at 10:46 PM, Tim Starlingtstarl...@wikimedia.org
wrote:
If we split up the extensions directory, each extension having its own
repository, then this will discourage developers from updating the
extensions in bulk. This affects
On 22 March 2011 18:00, Æ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.
Thanks to Ævar I realised that we're all missing the point and
assuming things which are never spoken out. These
On Wed, Mar 23, 2011 at 4:16 AM, Tim Starling tstarl...@wikimedia.org wrote:
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
2011/3/23 Tim Starling tstarl...@wikimedia.org:
I think our focus at the moment should be on deployment of extensions
and core features from the 1.17 branch to Wikimedia. We have heard on
several occasions that it is the delay between code commit and
deployment, and the difficulty in getting
On 11-03-22 07:46 PM, Tim Starling wrote:
[...]
If we split up the extensions directory, each extension having its own
repository, then this will discourage developers from updating the
extensions in bulk. This affects both interface changes and general
code maintenance. I'm sure
On 11-03-23 01:28 AM, Niklas Laxström wrote:
On 22 March 2011 18:00, Ævar Arnfjörð Bjarmasonava...@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.
Thanks to Ævar I realised that we're all missing the point and
Roan Kattouw roan.katt...@gmail.com wrote:
2011/3/23 Tim Starling tstarl...@wikimedia.org:
I disagree, however, that the backlog of trunk reviews is not
concerning. It means that we still haven't come up with a good process
for reliable and quick (as in time between commit and review) code
2011/3/23 Marcin Cieslak sa...@saper.info:
One of the ways to improve this is to assign mentors to new committers.
Mentors don't have to be necessarily related to the particular area
of committers work. The question is how many current developers
would have time to accommodate newbies, but
Daniel Friesen wrote:
- Brion mentioned there is prior art in hosting large numbers of git
repos. Gitorious' codebase is open-source and can be re-used. Wikimedia
could potentially host it's own gitorious for MediaWiki git repos.
I realised today that we are trying to adapt our layout to the
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/
On Tue, Mar 22, 2011 at 7:46 PM, Tim Starling tstarl...@wikimedia.org wrote:
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
On 3/22/11 6:05 PM, Rob Lanphier wrote:
Our code review tool is pretty nice, but we can't let it
be the tail that wags the dog.
At the risk of being impolite -- our code review tool is not that nice.
(I don't expect that anyone who worked on it would even disagree with me
here.)
It happens
On 11-03-23 12:41 PM, Rob Lanphier wrote:
On Tue, Mar 22, 2011 at 7:46 PM, Tim Starlingtstarl...@wikimedia.org wrote:
I'm not talking about the interfaces between core and extensions,
which are reasonably stable. I'm mainly talking mainly about the
interfaces which operate within and between
On 2011-03-23, Neil Kandalgaonkar wrote:
On 3/22/11 6:05 PM, Rob Lanphier wrote:
Our code review tool is pretty nice, but we can't let it
be the tail that wags the dog.
At the risk of being impolite -- our code review tool is not that nice.
(I don't expect that anyone who worked on it
On 3/23/11 2:13 PM, Robert Leverington wrote:
On 2011-03-23, Neil Kandalgaonkar wrote:
On 3/22/11 6:05 PM, Rob Lanphier wrote:
Our code review tool is pretty nice, but we can't let it
be the tail that wags the dog.
At the risk of being impolite -- our code review tool is not that nice.
(I
2011/3/23 Neil Kandalgaonkar ne...@wikimedia.org:
- There are other software frameworks for code review with more and
better features.
Yes, we should look at existing stuff for Git.
- There are other code review paradigms that are better for team health,
other than let's spend several months
On Thu, Mar 24, 2011 at 7:07 AM, Neil Kandalgaonkar ne...@wikimedia.org wrote:
It happens to be our home grown tool, and it uses a framework that more
of us are familiar with. But it's not such an overwhelming asset that we
should consider staying on SVN because of it. In 2011 there are lots of
Daniel Friesen wrote:
((And before anyone says anything, there's no way I'm putting private
keys on servers operated by a 3rd party, or doing development of things
on my local machine -- reconfiguring apache and trying to get packaged
apache and mysql to NOT start up on my laptop except
On 11-03-23 05:37 PM, Platonides wrote:
Daniel Friesen wrote:
((And before anyone says anything, there's no way I'm putting private
keys on servers operated by a 3rd party, or doing development of things
on my local machine -- reconfiguring apache and trying to get packaged
apache and mysql
Neil Kandalgaonkar wrote:
At the risk of being impolite -- our code review tool is not that nice.
(I don't expect that anyone who worked on it would even disagree with me
here.)
It's only impolite if you criticize the code review tool without being
constructive. What specifically do you not
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
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
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
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
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: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
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
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
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
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
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
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
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
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
On Sun, Mar 20, 2011 at 14:21, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote:
On Wed, Mar 16, 2011 at 19:26, Yuvi Panda yuvipa...@gmail.com wrote:
I noticed that there's a github mirror of the svn repository at
https://github.com/mediawiki, but it is rather out of date. Any idea
if/when it
55 matches
Mail list logo
