From: Stefan K. <ste...@eb...> - 2009-11-30 16:19:50
|
Hi Jonathan, thanks for getting involved in this, since it is really important. I will try to make clear what the problem from our point of view is. Let me use an example for this, but let me say that it is not about the people involved - it could be anybody. We submmitted a patch for one of the ControllerModules. This was done against _current Uppsala git_. The branch was not applied for weeks (and also no comment given why not). Then some patches by Arvid for the refactoring were applied. These clashed with our pending patches (which is not Arvids fault, since he could not know). Then we were told to rework our patches to comply with Arvid's _later_ changes. This is problematic for 3 reasons: 1. It takes a lot of time (obviously this was not just about 1 patch) 2. It is bound to introduce errors, since we had to rework our code against Arvid's changed code - if ours would have been applied first, Arvid would have changed it according to his code and he knows his code much better than us. 3. It turned out Arvid's code had some problems. That's fine, nobody's code is perfect, but if we would have seen his code in time, we could have commented on it and sorted out how to do that refactoring best. Considering this I believe and my experiences show that if we work on the same code together we need _immediate code integration_. Anything creating parallel repositories is bound to give chaos. "Repositories" here can mean GIT, SVN, patch tracker, emails to mailing list, whatever. Only immediate code integration saves us from that. In theory, this would be possible with the patch system as well, but since for the git masters it is just not possible to cope with patches on time, effectivly a common repository is the only workable solution. Ok, I hope I made that point clear. It is not about git or svn or me or egon or us or Uppsala or whatever, it is that _working together on the same code requires immediate code integration_ (which in practice means a shared repository). This is really all I have to say and can say about it. Stefan On Monday 30 November 2009 12:38:33 Jonathan Alvarsson wrote: > I am going to keep meddling in this discussion (let me again say that > I have not been personally involved in the JChempaint development and > I can only give the view from the outside) and offer my suggestion of > the source of the trouble. Could it be that this is the situation: > > When the Uppsala team ran into trouble with keeping track of all > branches and work that was taking place in different places they > introduced Git as a new solution for better handling the branches. But > the EBI developers did not get sufficiently informed about why this > was needed. For them things were working fine and Git was in fact not > a solution to a branch management problem but instead one hell of a > road bump. What for the Uppsala team was a salvation the EBI team saw > as a strange and complicated set of new rituals hindering them from > doing their job. Could it have happened somewhat like that? > > After having learned to work with Git myself I can easily see how this > is a possible situation. Git is a powerful tool but it is actually not > very much like SVN at all and learning to use it and taking the step > from SVN to Git can be very painful. (Ask me, I know all about the > pain of learning new tools) > > So could the source of this fork be about the step from SVN to Git? If > that is the case then maybe we could come up with a solution where the > EBI people keep using SVN and the Uppsala people uses Git. This is > entirely possible in my eyes. I feel that it would be sad if this > joint venture failed because it can not decide which version control > system to use... > > On the other hand there might be more profound differences between the > now two separate JChempaint projects than only the version control > system they are using. Is instead this the case? -- Stefan Kuhn B. Sc. M. A. Software Engineer in the Chemoinformatics and Metabolism Team European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2657 Fax +44 (0)1223 494 468 |
From: Christoph S. <ste...@eb...> - 2009-12-01 17:18:01
|
This (Stefan's text below) is a very good and balanced explanation of why things were not working for *us*. Again, this is not a people's problem but a problem of a system. Nothing animals were harmed in the production of this ... We were just looking for a solution that works for us and will be happy to work with everyone in the longer term to get to a unified working solution. *Right now*, in the current situation, we needed to act to get things done. So please, no need for arousal. Cheers, Chris On 30/11/2009 16:19, Stefan Kuhn wrote: > Hi Jonathan, > thanks for getting involved in this, since it is really important. I will try > to make clear what the problem from our point of view is. Let me use an > example for this, but let me say that it is not about the people involved - > it could be anybody. > We submmitted a patch for one of the ControllerModules. This was done against > _current Uppsala git_. The branch was not applied for weeks (and also no > comment given why not). Then some patches by Arvid for the refactoring were > applied. These clashed with our pending patches (which is not Arvids fault, > since he could not know). Then we were told to rework our patches to comply > with Arvid's _later_ changes. This is problematic for 3 reasons: > 1. It takes a lot of time (obviously this was not just about 1 patch) > 2. It is bound to introduce errors, since we had to rework our code against > Arvid's changed code - if ours would have been applied first, Arvid would > have changed it according to his code and he knows his code much better than > us. > 3. It turned out Arvid's code had some problems. That's fine, nobody's code is > perfect, but if we would have seen his code in time, we could have commented > on it and sorted out how to do that refactoring best. > Considering this I believe and my experiences show that if we work on the same > code together we need _immediate code integration_. Anything creating > parallel repositories is bound to give chaos. "Repositories" here can mean > GIT, SVN, patch tracker, emails to mailing list, whatever. Only immediate > code integration saves us from that. In theory, this would be possible with > the patch system as well, but since for the git masters it is just not > possible to cope with patches on time, effectivly a common repository is the > only workable solution. > Ok, I hope I made that point clear. It is not about git or svn or me or egon > or us or Uppsala or whatever, it is that _working together on the same code > requires immediate code integration_ (which in practice means a shared > repository). > This is really all I have to say and can say about it. > Stefan > > On Monday 30 November 2009 12:38:33 Jonathan Alvarsson wrote: >> I am going to keep meddling in this discussion (let me again say that >> I have not been personally involved in the JChempaint development and >> I can only give the view from the outside) and offer my suggestion of >> the source of the trouble. Could it be that this is the situation: >> >> When the Uppsala team ran into trouble with keeping track of all >> branches and work that was taking place in different places they >> introduced Git as a new solution for better handling the branches. But >> the EBI developers did not get sufficiently informed about why this >> was needed. For them things were working fine and Git was in fact not >> a solution to a branch management problem but instead one hell of a >> road bump. What for the Uppsala team was a salvation the EBI team saw >> as a strange and complicated set of new rituals hindering them from >> doing their job. Could it have happened somewhat like that? >> >> After having learned to work with Git myself I can easily see how this >> is a possible situation. Git is a powerful tool but it is actually not >> very much like SVN at all and learning to use it and taking the step >> from SVN to Git can be very painful. (Ask me, I know all about the >> pain of learning new tools) >> >> So could the source of this fork be about the step from SVN to Git? If >> that is the case then maybe we could come up with a solution where the >> EBI people keep using SVN and the Uppsala people uses Git. This is >> entirely possible in my eyes. I feel that it would be sad if this >> joint venture failed because it can not decide which version control >> system to use... >> >> On the other hand there might be more profound differences between the >> now two separate JChempaint projects than only the version control >> system they are using. Is instead this the case? > > > -- Dr. Christoph Steinbeck Head of Chemoinformatics and Metabolism European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2640 Video meliora proboque deteriora sequor. ... Ovid, Metamorphoses VII, 20/21 |