From: Christoph S. <ste...@eb...> - 2009-11-28 13:55:36
|
Dear all, after revamping the JChemPaint applet completely and including it into our EBI chemistry database ChEBI (http://www.ebi.ac.uk/chebi) as part of the production systems, we have decided to make some changes to our internal production process of the applet of which we would like to make you aware: For development of the JChempaint applet, we have now decided to permanently fork the 'controller' and 'renderer' packages They now live in the JChemPaint svn repository on SourceForge and were renamed to org.openscience.jchempaint.* to avoid confusion and to allow to provide a stable applet which works reliably with our production databases at EBI. Anybody wishing to conribute to the development of the JChemPaint Applet/Swing version should work with svn and master, there is also a page explaining it at https://sourceforge.net/apps/mediawiki/cdk/index.php?title=JChemPaint#Development. This setup is not ideal, but we found the current working model not productive, having to spend to much work on reworking patches and slowing us down from making a release and looking into new features. We will of course follow the development of the CDK renderer/controller packages and port new developments from time to time. This JCP repository compiles with cdk master. We also made some patches outside renderer/controller, these have been filed as patches. Since we want to release JCP 3.0 asap based on the svn repository and master, we would like to see these applied (could we ask cdk developers to have a look at them?) Greetings from Cambridge, Christoph, Stefan and Mark -- 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 |
From: Egon W. <ego...@gm...> - 2009-11-29 10:11:54
|
Dear Chris, On Sat, Nov 28, 2009 at 2:55 PM, Christoph Steinbeck <ste...@eb...> wrote: > For development of the JChempaint applet, we have now decided to > permanently fork the 'controller' and 'renderer' packages I am sorry to hear that you feel this is needed. > They now live in the JChemPaint svn repository on SourceForge and were > renamed to org.openscience.jchempaint.* to avoid confusion and to allow > to provide a stable applet which works reliably with our production > databases at EBI. Can you elaborate what exactly has been forked? Versions, etc? Arvid was in the past two weeks writing up a summary and plan on how to integrated the patched developed by Mark and Stefan, and I have (except the last 3-4 weeks, where I have been busy with other research things) working my way through patches from the EBI branch. What of this is now still relevant? > Anybody wishing to conribute to the development of the JChemPaint > Applet/Swing version should work with svn and master, there is also a > page explaining it at > https://sourceforge.net/apps/mediawiki/cdk/index.php?title=JChemPaint#Development. I had rather seen this sentence give a bit more detail... The JChemPaint-Primary work is still set up to release an applet and Swing version; so anyone who wishes to contribute to the JChemPaint Applet/Swing version is also most welcome to contribute to that ongoing effort. > This setup is not ideal, but we found the current working model not > productive, having to spend to much work on reworking patches and > slowing us down from making a release and looking into new features. Yes, the same was noted about a year ago from our side, where the development model used at that time was leading to unproductivity in the development of JChemPaint (the one using SWT widgets). This lead to a changed development model, and I am sorry to hear that this second iteration of development model is not working either. I am even more sorry to hear that you do not even see options anymore is attempting a third iteration and that you feel a fork is inevitable. > We will of course follow the development of the CDK renderer/controller > packages and port new developments from time to time. Collaboration is never easy, and it is a shame that JChemPaint 3.0 (now in two forks) is now no longer "Using the Collaborative Forces of the Internet" as did the first version. > This JCP repository compiles with cdk master. We also made some patches > outside renderer/controller, these have been filed as patches. Since we > want to release JCP 3.0 asap based on the svn repository and master, we > would like to see these applied (could we ask cdk developers to have a > look at them?) This brings as to a more serious problem of this fork. There now are two JChemPaint forks, both of which require patches in the CDK. I have reworked some of Gilleain, Stefans and my original patches in JChemPaint-Primary, which I am not sure are picked up by JChemPaint-EBI. Either case, it seems that both versions of things are now up to review by CDK developers... (the jchempaint-primary versions of those required CDK patches are listed in the 0-other branch at [0] and also filed in the CDK patch system for review). Christoph, I strongly suggest we work out at least these required CDK patches between your and our team, and do not require other CDK developers to get too deeply involved in issues resulting from this fork. Egon 0.http://pele.farmbio.uu.se/cgi-bin/gitweb.cgi?p=jchempaint-primary.git;a=shortlog;h=refs/heads/0-other -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Jonathan A. <jon...@gm...> - 2009-11-29 13:49:32
|
On Sat, Nov 28, 2009 at 2:55 PM, Christoph Steinbeck <ste...@eb...> wrote: > Dear all, > > after revamping the JChemPaint applet completely and including it into > our EBI chemistry database ChEBI (http://www.ebi.ac.uk/chebi) as part of > the production systems, we have decided to make some changes to our > internal production process of the applet of which we would like to make > you aware: > > For development of the JChempaint applet, we have now decided to > permanently fork the 'controller' and 'renderer' packages > > They now live in the JChemPaint svn repository on SourceForge and were > renamed to org.openscience.jchempaint.* to avoid confusion and to allow > to provide a stable applet which works reliably with our production > databases at EBI. > > Anybody wishing to conribute to the development of the JChemPaint > Applet/Swing version should work with svn and master, there is also a > page explaining it at > https://sourceforge.net/apps/mediawiki/cdk/index.php?title=JChemPaint#Development. > > This setup is not ideal, but we found the current working model not > productive, having to spend to much work on reworking patches and > slowing us down from making a release and looking into new features. We > will of course follow the development of the CDK renderer/controller > packages and port new developments from time to time. > > This JCP repository compiles with cdk master. We also made some patches > outside renderer/controller, these have been filed as patches. Since we > want to release JCP 3.0 asap based on the svn repository and master, we > would like to see these applied (could we ask cdk developers to have a > look at them?) > > Greetings from Cambridge, > > Christoph, Stefan and Mark > This strikes me as sad news. Although I am not personally involved in JChempaint devlopment it is a key feature in my projects and I really hate to see this joint adventure come crashing down. Even though I am not at all familiar with this code base I want to express the feeling of big failure that these news bring me. I look around and I see a lot of people working on similar things repeating each others mistakes and general efforts. And I keep asking myself: Wouldn't it be better if we worked together? In this case you are not only working on similar things but upto a short while ago you were in fact working on the same things. I can only urge you to think this over one more time. Are you really sure that it is bad invested time to do the merge in order to be able to keep (to use the words used by Egon) "Using the Collaborative Forces of the Internet". Is it not an option to do the merge and try another work method after that? As a side note I wonder about the statement: "having to spend to much work on reworking patches". In my ears this seems wrong indeed and I am very curious, in order to learn something from this (so that I don't myself end up in a similar situation), where does this need come fom? Why are you reworking patches? Could it be that the time between merging has been to long and too many changes has turned up in the code? If so, this sounds like an indication that many people are making heavy contributions to this code. Are you sure it is not worth the effort in order to keep getting this free source of patches to the code you are running? And try to keep the branches more tightly merged in the future? I feel there must be a lesson to be learned somewhere in this... -- // Jonathan |
From: Egon W. <ego...@gm...> - 2009-11-30 11:29:55
|
On Sun, Nov 29, 2009 at 2:42 PM, Jonathan Alvarsson <jon...@gm...> wrote: > As a side note I wonder about the statement: "having to spend to much > work on reworking patches". In my ears this seems wrong indeed and I > am very curious, in order to learn something from this (so that I > don't myself end up in a similar situation), where does this need come > fom? Why are you reworking patches? For example, because of API changes in the CDK. Right now, I am rewriting a few patches that used 'new LoggingTool()' where the current CDK master code uses the LoggingToolFactory for that. > Could it be that the time between merging has been to long and too > many changes has turned up in the code? Yes. > If so, this sounds like an indication that many people are making heavy > contributions to this code. Are you sure it is not worth the effort in order to > keep getting this free source of patches to the code you are running? And try to > keep the branches more tightly merged in the future? Both the EBI and the Uppsala team have invested enough time to get things together, and I very much respect the EBI decision to fork. Their needs is not currently not compatible with the design updates the JChemPaint rendering and editing code is undergoing. > I feel there must be a lesson to be learned somewhere in this... Sure. Large projects are difficult to maintain; particular when needs and wishes between partners are (too far) apart. I'm convinced the two projects will merge at some point again, and looking forward to that moment. In that respect, I am hoping the fork is not really permanent, but temporarily permanent. I'm hoping Christoph will elaborate on this more. Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Rajarshi G. <raj...@gm...> - 2009-11-29 15:52:15
|
This is unfortunate news. I echo Jonathans' comments - while I'm not a developer of the JCP code, I certainly make use of the underlying components (such as the renderer). If the main bottleneck that led to this fork is the merging of patches into the CDK - couldn't the review process be made simpler, if patches are localized to the renderer/controller packages? As a CDK dev I'm happy to review patches, but for stuff related to JCP it's a little difficult since I do not know that portion of the code and my review would necessarily be cursory. So wouldn't it be better for patches related to these two packages, to just let JCP devs check with each other and then commit? On Nov 28, 2009, at 8:55 AM, Christoph Steinbeck wrote: > Dear all, > > after revamping the JChemPaint applet completely and including it into > our EBI chemistry database ChEBI (http://www.ebi.ac.uk/chebi) as > part of > the production systems, we have decided to make some changes to our > internal production process of the applet of which we would like to > make > you aware: > > For development of the JChempaint applet, we have now decided to > permanently fork the 'controller' and 'renderer' packages > > They now live in the JChemPaint svn repository on SourceForge and were > renamed to org.openscience.jchempaint.* to avoid confusion and to > allow > to provide a stable applet which works reliably with our production > databases at EBI. ---------------------------------------------------- Rajarshi Guha | NIH Chemical Genomics Center http://www.rguha.net | http://ncgc.nih.gov ---------------------------------------------------- Entropy requires no maintenance. -- Markoff Chaney |
From: Egon W. <ego...@gm...> - 2009-11-29 16:08:59
|
Hi Rajarshi, On Sun, Nov 29, 2009 at 4:52 PM, Rajarshi Guha <raj...@gm...> wrote: > If the main bottleneck that led to this fork is the merging of patches > into the CDK - couldn't the review process be made simpler, if patches > are localized to the renderer/controller packages? Patches in those two packages are actually not difficult because of needed review. Those patches are not really reviewed at all yet; instead, it's the fact that things were already somewhat forked, as both JChemPaint-SWT and JChemPaint-Swing used snapshots of renderer and controller module. > As a CDK dev I'm happy to review patches, but for stuff related to JCP > it's a little difficult since I do not know that portion of the code > and my review would necessarily be cursory. The new renderer and controller code should not be reviewed at all yet; I do not feel Christoph was suggesting this either. However, there are some smaller changes needed in the CDK library itself (such as in the 0-other branch, but also some patches in the EBI branch). Those patches to existing (non-rendered, non-controller) code are all in the CDK patch tracker. > So wouldn't it be better for patches related to these two packages, to > just let JCP devs check with each other and then commit? I think so. This was the whole idea behind the jchempaint-primary patch set. Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Rajarshi G. <raj...@gm...> - 2009-11-29 16:12:32
|
On Nov 29, 2009, at 11:08 AM, Egon Willighagen wrote: > Hi Rajarshi, > > The new renderer and controller code should not be reviewed at all > yet; I do not feel Christoph was suggesting this either. However, > there are some smaller changes needed in the CDK library itself (such > as in the 0-other branch, but also some patches in the EBI branch). > > Those patches to existing (non-rendered, non-controller) code are all > in the CDK patch tracker. Aah, OK. I'll clear of a few patches today then ---------------------------------------------------- Rajarshi Guha | NIH Chemical Genomics Center http://www.rguha.net | http://ncgc.nih.gov ---------------------------------------------------- A list is only as strong as its weakest link. -- Don Knuth |
From: Cyrus H. <ch...@bo...> - 2009-11-29 17:27:06
|
Dear CDK Developers, Having not actually contributed a single line of code, it's easy for me to stand back and lob suggestions/critiques, so bear that in mind as you read this. First of all, I'd like to say that I think that CDK and JChemPaint are important, worthwhile projects that have the potential to be very useful to a large community. My personal interests are in being able to represent (in the abstract, not visualization sense), compute on, read to and from various file formats and, to a lesser degree for the moment, to be able to interactively draw/edit various compounds. CDK and JChemPaint sound like good fits for this. I like the fact that the project is open source, that there is a relatively active developer community and that "brand name" groups like EBI are involved. This all sounds very promising to me. However, when I actually go to use CDK/JChemPaint I find a confusing picture. My MO is generally in digging into a project like this is to look at the website, find the tip of the development tree, download the latest and greatest, assess the situation of the code and try to make some toy examples to put the thing to work. Trying to do so with CDK and JChemPaint is, shall we say, frustrating, to say the least. I notice that the main wiki page and the source docs have gotten a bit better recently. Now at least there are links to both the SVN and git repos on the source page. But, why have two repositories? git's nice and appears to be the only way that development is getting done ("Branches on SourceForge will *not* be used for development; distributed branches outside SourceForge will be used for this instead."). SUGGESTION 1: Why not just get rid of the SVN repo? It seems like a source of confusion to have this _and_ a canonical git repo. Why would anyone want access to the code via the SVN repo at this point? At a minimum, supporting it in read-only mode as a deprecated service for folks who refuse to use git might make sense. But my read on this is that if you want to develop for CDK you need to be using git. So, eliminate a potential source of confusion by removing (or at least deprecating) the SVN repo. Another potential source of confusion is the relationship between JChemPaint and CDK. From the JChemPaint wiki page: "JChemPaint (or JCP for short here) is the editor and viewer included in CDK for 2D chemical structures. It is implemented in several forms: a Java application and two varieties of Java applet." My reading of this is that this is no longer true. I think this is a good thing. I think there should be a clear separation between the data representation/shared utilities/computational/IO/etc... pieces and GUI applications that use these things. At the risk of being back on topic to the original message, I don't see forking JCP as a bad thing, I see the confusing state of the underlying libraries as being a bad thing. But, back to the specifics of why it's hard for a new developer to begin working with JChemPaint. Well, before getting back to specifics, one more generality. I'm not a big fan of either sourceforge or wiki pages. I feel like both of these give suboptimal solutions to the problem at hand, but, this isn't a showstopper. I would rather see something like gitweb and a bare git server, or perhaps github for the canonical repository for the project. I'm also of the opinion that wiki pages get staler quicker than traditional web sites, but that could be a mistaken impression -- yet it's an opinion that is supported by the current state of the CDK and JCP web pages, if you ask me. Ok, back to specifics. How does one get JChemPaint? "JChemPaint is developed as a SourceForge project under CDK's SF Project Page. SourceForge gives us bugtracking, mailing lists, support manager and last not least SVN access." Ok, fine keep the bugtracking and mailing lists if no one wants to step up and host these at their home institution. Understandable. But what does "developed as a SourceForge project under CDK's SF Project Page" mean? Does that mean that there is only one mailing list, one bug tracker, etc...? It would be nice if there were direct links to any JCP resources directly from this page. "If you want to write documentation or start coding, please check the SourceForge site documentation on how to access the CVS. If you actively want to contribute, please get a SourceForge account, contact the project admin so that he can add you to the developers list. The next step would be to checkout the source code." I would assume that would be contributors know how to access the various repo's. Have a beginners guide if you must, but the limited space of the main JCP wiki page should instead point to the current repo for the code, not to SF documentation along with a presumably outdated note about a long-gone (?) CVS repo. "To get the stable release (JCP2), go for the "JChemPaint, version 2.4.x" link. To try the experimental release (JCP3), use the "JChemPaint (development), version 2.5.x" link." Umm... so stable (v2) is under 2.4 and experimental (v3) is under 2.5? Who's the one with the difficulties counting? This seems rather silly. And there's no link to repositories to get either v2/2.4 or v3/2.5 from here, as one might expect. There is a link to a page at EBI with a bunch of jar files. Perhaps I'm wrong, but i can't imagine folks wanting to download jar files of experimental versions of software such as this. I would imagine that if they're working with an experimental version they would want the code and to build their own jars. Links to the appropriate repositories would be nice. And, hey, if it's going to be JCP3, let's change the version number everywhere. Abandon v2.5 if you need to, but let's have a repository for JCP3. SUGGESTION 2: Have links to the appropriate repositories for JCP on the main JCP wiki page. Note that there is no mention of egonw's git repo, steinbeck's repo, jchempaint-primary or the like on any of the pages mentioned so far. Should one get wind of this branch via the mailing list or irc channel, etc..., one might google for it and find that there is a branch in the SVN repo called jchempaint-primary -- that hasn't been touched in 4 months. That makes this an unlikely candidate for the repo for the most active branch of the project... SUGGESTION 3: If you're going to rely on distributed git servers, make a canonical list of those servers and place it prominently on the developer documentation pages. Explain the rationale behind the different git servers. I'm a big fan of distributed VCSes, but I don't see where the need to be so many canonical-ish VCSes around. I was under the impression that one of the nice things about git was that distributed repo's could be synced up. Why can't we ensure that everything gets into one git repo with some frequency? Why have a git repo for only the canonical, numbered releases, and one repo each for group making extensive changes? I'm not opposed to local repos, indeed, we use them all the time when committing to our local machines, but why not ensure that commits from those repos go onto a central repo? One final gripey question about the current state of the repos is "why so many rebases for egonw's commits?" rebase is one of those features of git that I try to avoid using. When I see this sort of thing it suggests to me that there was probably a better way to achieve the same ends. But, then again, I don't really understand the relationship between, say, egonw's changes and jcp-primary. SUGGESTION 4: Lose the jchempaint-primary name. It's rather confusing to have the branch named after something that isn't in the repo. I get that this is the version that's supposed to be used with the (a?) current JCP branch, but how about if we name this release of CDK with a number or which something that is an inherent feature provided by the changes not just something that implies that this version has a bunch of changes that are required to work with some future-ish version of an application that uses this SDK. Numbers are cheap. Feel free to burn one and call the upcoming JCP release JCP4 and say that it requires CDK4 -- assuming that this stuff is really meant to represent the future tip of CDK, not a permanent fork. If it's a permanent fork of CDK, call it something like EBICDK or some such, rather than jchempaint-primary/CDK. The relationship between CDK and JCP is confusing enough without actually calling a branch of CDK "jchempaint-foo". I hope this doesn't all come across as too much whiney complaining from a lurker, but I thought it might help to hear how the project(s) look(s) to someone from the outside. I have high hopes for CDK, but I'd rather see developers' energy go into things like proper SMILES parsing and 2-d rendering of geometric isomers, to single out a feature that prevents me from using any version of CDK for real work at the moment, than sorting out the various repo/fork issues. I think it's neither surprising nor necessarily bad that folks want to have different applets/applications that use CDK, even for similar purposes. What would be nice would be to continue factor shared components out of these. If the EBI group wants their own visualization app, great, but let's make sure the underlying foundations are solid. Oh, one final note, it seems that there is a fair amount of infrastructure required for coordinating changes (patch tracker, various repos, bug tracker, reviews, etc...) It seems that this is a small enough community that trust and communication (on the mailing list, in IRC, etc...) could provide the same or better level of stability in the repos and allow folks to get their work done more efficiently. But then again I'm making yet another baseless claim merely on extrapolating from my experience with other projects. To all of the CDK and JCP developers, thanks for all of your hard work and I look forward to using and, hopefully, contributing to the project in the future. Sincerely, Cyrus Harmon On Nov 29, 2009, at 2:11 AM, Egon Willighagen wrote: > Dear Chris, > > On Sat, Nov 28, 2009 at 2:55 PM, Christoph Steinbeck > <ste...@eb...> wrote: >> For development of the JChempaint applet, we have now decided to >> permanently fork the 'controller' and 'renderer' packages > > I am sorry to hear that you feel this is needed. > >> They now live in the JChemPaint svn repository on SourceForge and were >> renamed to org.openscience.jchempaint.* to avoid confusion and to allow >> to provide a stable applet which works reliably with our production >> databases at EBI. > > Can you elaborate what exactly has been forked? Versions, etc? > > Arvid was in the past two weeks writing up a summary and plan on how > to integrated the patched developed by Mark and Stefan, and I have > (except the last 3-4 weeks, where I have been busy with other research > things) working my way through patches from the EBI branch. > > What of this is now still relevant? > >> Anybody wishing to conribute to the development of the JChemPaint >> Applet/Swing version should work with svn and master, there is also a >> page explaining it at >> https://sourceforge.net/apps/mediawiki/cdk/index.php?title=JChemPaint#Development. > > I had rather seen this sentence give a bit more detail... > > The JChemPaint-Primary work is still set up to release an applet and > Swing version; so anyone who wishes to contribute to the JChemPaint > Applet/Swing version is also most welcome to contribute to that > ongoing effort. > >> This setup is not ideal, but we found the current working model not >> productive, having to spend to much work on reworking patches and >> slowing us down from making a release and looking into new features. > > Yes, the same was noted about a year ago from our side, where the > development model used at that time was leading to unproductivity in > the development of JChemPaint (the one using SWT widgets). > > This lead to a changed development model, and I am sorry to hear that > this second iteration of development model is not working either. I am > even more sorry to hear that you do not even see options anymore is > attempting a third iteration and that you feel a fork is inevitable. > >> We will of course follow the development of the CDK renderer/controller >> packages and port new developments from time to time. > > Collaboration is never easy, and it is a shame that JChemPaint 3.0 > (now in two forks) is now no longer "Using the Collaborative Forces of > the Internet" as did the first version. > >> This JCP repository compiles with cdk master. We also made some patches >> outside renderer/controller, these have been filed as patches. Since we >> want to release JCP 3.0 asap based on the svn repository and master, we >> would like to see these applied (could we ask cdk developers to have a >> look at them?) > > This brings as to a more serious problem of this fork. There now are > two JChemPaint forks, both of which require patches in the CDK. I have > reworked some of Gilleain, Stefans and my original patches in > JChemPaint-Primary, which I am not sure are picked up by > JChemPaint-EBI. Either case, it seems that both versions of things are > now up to review by CDK developers... (the jchempaint-primary versions > of those required CDK patches are listed in the 0-other branch at [0] > and also filed in the CDK patch system for review). > > Christoph, I strongly suggest we work out at least these required CDK > patches between your and our team, and do not require other CDK > developers to get too deeply involved in issues resulting from this > fork. > > Egon > > 0.http://pele.farmbio.uu.se/cgi-bin/gitweb.cgi?p=jchempaint-primary.git;a=shortlog;h=refs/heads/0-other > > -- > Post-doc @ Uppsala University > Homepage: http://egonw.github.com/ > Blog: http://chem-bla-ics.blogspot.com/ > PubList: http://www.citeulike.org/user/egonw/tag/papers > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel |
From: Egon W. <ego...@gm...> - 2009-11-29 18:46:22
|
Hi Cyrus, On Sun, Nov 29, 2009 at 5:56 PM, Cyrus Harmon <ch...@bo...> wrote: > SUGGESTION 4: Lose the jchempaint-primary name. Yeah, that's historical; the name originates from the fact that for a long that people have been working in branches, and the branch on Pele was the primary branch, where patches were collected. The 'primary' does not refer to a number. I am happy with whatever name, though I am not sure what the name should be; not at this time anyway. > Oh, one final note, it seems that there is a fair amount of infrastructure required for coordinating changes (patch tracker, various repos, bug tracker, reviews, etc...) It seems that this is a small enough community that trust and communication (on the mailing list, in IRC, etc...) could provide the same or better level of stability in the repos and allow folks to get their work done more efficiently. But then again I'm making yet another baseless claim merely on extrapolating from my experience with other projects. The number of people working on the renderer and controller modules is actually not so large: two at the EBI, two in Uppsala. Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Syed A. R. <s9...@go...> - 2009-11-29 19:43:48
|
Dear CDK Developers, I have been an active user of CDK for the past 5-6 years and much of my previous/present research work is based on CDK and JCP. My only present contribution to the development front has been in the form of the SMSD software (http://pele.farmbio.uu.se/nightly-smsd/) for calculting MCS. I believe that over the years both CDK and JCP have become a brand name in ChemInformatics with a set of very efficient, enthusiastic and dedicated code developers. My current work heavily depends on the JCP and CDK. Recently, I tried the JCP from EBI which looks really promising and I thought of using it in my current research work. On the other hand I have integrated SMSD with CDK master on GIT, which is the latest version of the CDK (with latest patches and bug fixed). Now when I *combined these two codes* it gave me a lot of exceptions/failures while compiling as they didn't agree with each other. As a well wisher of this project I would request the developers to join hands with each other to make the CDK and JCP a Cheminformatics "ICON". What I would suggest would be to hold on to the present and future feature developments until..... a) We organize a BUG fix retreat ASAP for 2-3 days and iron out the bugs. b) Synchronize the efforts of JCP developers and CDK core code developers (most of the time they are the same folks). c) Release a stable version which should be the starting point for the next value added developments. d) Choose one repository SVN or GIT (the whole idea should be every one should have the latest copy of the code in order to avoid this confusion). Apologies if I sound too ambitious. I sincerely believe that a joint effort and a clear mandate would help the CDK and JCP to attract and maintain its user base. Good luck! Asad Christoph Steinbeck wrote: > Dear all, > > after revamping the JChemPaint applet completely and including it into > our EBI chemistry database ChEBI (http://www.ebi.ac.uk/chebi) as part of > the production systems, we have decided to make some changes to our > internal production process of the applet of which we would like to make > you aware: > > For development of the JChempaint applet, we have now decided to > permanently fork the 'controller' and 'renderer' packages > > They now live in the JChemPaint svn repository on SourceForge and were > renamed to org.openscience.jchempaint.* to avoid confusion and to allow > to provide a stable applet which works reliably with our production > databases at EBI. > > Anybody wishing to conribute to the development of the JChemPaint > Applet/Swing version should work with svn and master, there is also a > page explaining it at > https://sourceforge.net/apps/mediawiki/cdk/index.php?title=JChemPaint#Development. > > This setup is not ideal, but we found the current working model not > productive, having to spend to much work on reworking patches and > slowing us down from making a release and looking into new features. We > will of course follow the development of the CDK renderer/controller > packages and port new developments from time to time. > > This JCP repository compiles with cdk master. We also made some patches > outside renderer/controller, these have been filed as patches. Since we > want to release JCP 3.0 asap based on the svn repository and master, we > would like to see these applied (could we ask cdk developers to have a > look at them?) > > Greetings from Cambridge, > > Christoph, Stefan and Mark > > |
From: Stefan K. <ste...@eb...> - 2009-11-30 09:44:02
|
> Patches in those two packages are actually not difficult because of > needed review. Those patches are not really reviewed at all yet; > instead, it's the fact that things were already somewhat forked, as > both JChemPaint-SWT and JChemPaint-Swing used snapshots of renderer > and controller module. I am sorry, but this is not true. We have worked with your repository in Uppsala, and we have rebased that. The problem came from patches not being applied for a very long time, which made us unaware of what other people are doing (and other people anaware of what we are doing) and made patches clash with each other. You might call it a fork, but then it was a forced fork because of non-application of patches. We did never anything which made a fork or even a branch. > > So wouldn't it be better for patches related to these two packages, to > > just let JCP devs check with each other and then commit? > > I think so. This was the whole idea behind the jchempaint-primary patch > set. If we wanted to do that setup, we either need a common repository or patches must be applied immediately. If patches (ours or Arvids or somebody elses) do not get applied, there is no point in talking about "need not to be reviewed" and "just check and commit" etc. Stefan -- 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: Egon W. <ego...@gm...> - 2009-11-30 10:02:54
|
On Mon, Nov 30, 2009 at 10:43 AM, Stefan Kuhn <ste...@eb...> wrote: >> Patches in those two packages are actually not difficult because of >> needed review. Those patches are not really reviewed at all yet; >> instead, it's the fact that things were already somewhat forked, as >> both JChemPaint-SWT and JChemPaint-Swing used snapshots of renderer >> and controller module. > > I am sorry, but this is not true. We have worked with your repository in > Uppsala, and we have rebased that. The problem came from patches not being > applied for a very long time, which made us unaware of what other people are > doing (and other people anaware of what we are doing) and made patches clash > with each other. You might call it a fork, I used "somewhat forked". Forking is the extreme of branching; more permanent indeed. That was indeed not the case yet. I should have used "branched". I apologize for using the confusing use of "somewhat forked". > but then it was a forced fork > because of non-application of patches. We did never anything which made a > fork or even a branch. A snapshot was taken, from which things were further developed. That's a branch to me. The fork did not happen until this weekend. >> > So wouldn't it be better for patches related to these two packages, to >> > just let JCP devs check with each other and then commit? >> >> I think so. This was the whole idea behind the jchempaint-primary patch >> set. > > If we wanted to do that setup, we either need a common repository or patches > must be applied immediately. There is no technical need for that. But also see below. > If patches (ours or Arvids or somebody elses) do not get applied, I am not sure where you do get the impression that patches are not being applied to the main jchempaint branch. That patches take long to get applied is *not* merely a function of someone applying them... it actually depends on the patch too... and the fact that the patch needs to be compatible, and not depend on incompatible patches... > there is no point in talking about "need not to be reviewed" > and "just check and commit" etc. There is *no* review in the sense the CDK code is peer reviewed, but yes there are very basic peer review involved: 1. a patch must apply 2. it most be compatible with what is already in the repository (e.g. in terms of design) If you like to call that review, sure. But that's not review in the sense we review CDK patches. Yes, I have been asking about updates towards CDK stable too. So, add that as 3. if your like. But the jchempaint-primary is primarily about finishing a new design, and patches that do not conform the design are much less easy to apply, causing delay... If the EBI branch would contain nice, clean patches, applying them would be so much easier. But it is rather time consuming to find which of the EBI patches depend on each other, correct each other, and filter out those that are compatible with the new design. That's the cause of the delay in patch application... not any formal kind of review. At least, from my perspective. Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Stefan K. <ste...@eb...> - 2009-11-30 10:29:04
|
> > but then it was a forced fork > > because of non-application of patches. We did never anything which made a > > fork or even a branch. > > A snapshot was taken, from which things were further developed. That's > a branch to me. The fork did not happen until this weekend. What snapshot are you talking about? We did a clone of your repository, which we rebased frequently and worked on that. Where is the snapshot? If you mean that each git repository is a sort of snapshot, that might be true, but is inherent to git. Stefan -- 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: Egon W. <ego...@gm...> - 2009-11-30 11:00:22
|
On Mon, Nov 30, 2009 at 11:28 AM, Stefan Kuhn <ste...@eb...> wrote: >> A snapshot was taken, from which things were further developed. That's >> a branch to me. The fork did not happen until this weekend. > > What snapshot are you talking about? We did a clone of your repository, which > we rebased frequently and worked on that. Where is the snapshot? Like you say, a snapshot := a certain git commit. > If you mean that each git repository is a sort of snapshot, that might be true, but is > inherent to git. Yes, and there was also no implied judgement in using a snapshot; this is inherit to development. JChemPaint-Primary is using snapshots of the the CDK: the current version on Pele is using CDK 1.3.0, and I am now rewriting the patches to use CDK 1.3.1 (this will keep me busy for the rest of the day). And, likewise, Bioclipse is using a snapshot of JChemPaint-Primary... those are identified by the 1.3.0.0bioclipseX tags also available on the Pele jchempaint-primary git repository. You'll also see that the Bioclipse branch has some patches on top of but changing jchempaint-primary which have not found their way into the main branches. Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Stefan K. <ste...@eb...> - 2009-11-30 10:54:02
|
> SUGGESTION 1: Why not just get rid of the SVN repo? It seems like a source > of confusion to have this _and_ a canonical git repo. Why would anyone want > access to the code via the SVN repo at this point? At a minimum, supporting > it in read-only mode as a deprecated service for folks who refuse to use > git might make sense. But my read on this is that if you want to develop > for CDK you need to be using git. So, eliminate a potential source of > confusion by removing (or at least deprecating) the SVN repo. I think there are two issues here: 1. Why have two repositories? Well the reason is it was decided by the community not to have jcp in cdk. So we need a second repository (or project in repository or whatever, but a second place). If this is in SVN or GIT is not really the point, although I feel SVN does the job better. > Another potential source of confusion is the relationship between > JChemPaint and CDK. From the JChemPaint wiki page:... 2. This all relates to documentation. The central documentation for JCP is the wiki page at https://sourceforge.net/apps/mediawiki/cdk/index.php?title=JChemPaint and I did my best to keep this up to date, there is also a section on "Checking out JCP". That there is different information in other places, then this is due to stuff being moved round and back and forth and blah all the time. I am never a big fan of that, because it firstly takes so much time and it secondly is bound to make bits of wrong information lying round everywhere. But since certain things have been decided by the community, we have to make them work. I take care of the jcp page and pages linked from there and will correct things somewhere else if I find them, but there is no guarantee I get them all. > would be nice. And, hey, if it's going to be JCP3, let's change the version > number everywhere. Abandon v2.5 if you need to, but let's have a repository > for JCP3. JCP 3.0 will be released soon (hopefully this week). > > SUGGESTION 2: Have links to the appropriate repositories for JCP on the > main JCP wiki page. For my understanding, https://sourceforge.net/apps/mediawiki/cdk/index.php?title=Checking_out_JCP gives these. > > Note that there is no mention of egonw's git repo, steinbeck's repo, > jchempaint-primary or the like on any of the pages mentioned so far. These are all not needed for JCP development - you only need git master and the svn repository. > Should > one get wind of this branch via the mailing list or irc channel, etc..., > one might google for it and find that there is a branch in the SVN repo > called jchempaint-primary -- that hasn't been touched in 4 months. That > makes this an unlikely candidate for the repo for the most active branch of > the project... This has been moved to GIT, but JCP is using master now. > One final gripey question about the current state of the repos is "why so > many rebases for egonw's commits?" rebase is one of those features of git > that I try to avoid using. When I see this sort of thing it suggests to me > that there was probably a better way to achieve the same ends. But, then > again, I don't really understand the relationship between, say, egonw's > changes and jcp-primary. I can't comment on that, please let Egonw explain this to you. > > SUGGESTION 4: Lose the jchempaint-primary name. It's rather confusing to This is actually lost. I think we should delete the jcp-primary branch from svn. I see no reason not to do that. Egonw, what do you think? > I hope this doesn't all come across as too much whiney complaining from a > lurker, but I thought it might help to hear how the project(s) look(s) to > someone from the outside. I have high hopes for CDK, but I'd rather see > developers' energy go into things like proper SMILES parsing and 2-d > rendering of geometric isomers, to single out a feature that prevents me > from using any version of CDK for real work at the moment, than sorting out > the various repo/fork issues. > > I think it's neither surprising nor necessarily bad that folks want to have > different applets/applications that use CDK, even for similar purposes. > What would be nice would be to continue factor shared components out of > these. If the EBI group wants their own visualization app, great, but let's > make sure the underlying foundations are solid. I can only share this view. But in order to do that sharing we need a working development setup. > On Nov 29, 2009, at 2:11 AM, Egon Willighagen wrote: > > Dear Chris, > > > > On Sat, Nov 28, 2009 at 2:55 PM, Christoph Steinbeck > > > > <ste...@eb...> wrote: > >> For development of the JChempaint applet, we have now decided to > >> permanently fork the 'controller' and 'renderer' packages > > > > I am sorry to hear that you feel this is needed. > > > >> They now live in the JChemPaint svn repository on SourceForge and were > >> renamed to org.openscience.jchempaint.* to avoid confusion and to allow > >> to provide a stable applet which works reliably with our production > >> databases at EBI. > > > > Can you elaborate what exactly has been forked? Versions, etc? > > > > Arvid was in the past two weeks writing up a summary and plan on how > > to integrated the patched developed by Mark and Stefan, and I have > > (except the last 3-4 weeks, where I have been busy with other research > > things) working my way through patches from the EBI branch. > > > > What of this is now still relevant? > > > >> Anybody wishing to conribute to the development of the JChemPaint > >> Applet/Swing version should work with svn and master, there is also a > >> page explaining it at > >> https://sourceforge.net/apps/mediawiki/cdk/index.php?title=JChemPaint#De > >>velopment. > > > > I had rather seen this sentence give a bit more detail... > > > > The JChemPaint-Primary work is still set up to release an applet and > > Swing version; so anyone who wishes to contribute to the JChemPaint > > Applet/Swing version is also most welcome to contribute to that > > ongoing effort. > > > >> This setup is not ideal, but we found the current working model not > >> productive, having to spend to much work on reworking patches and > >> slowing us down from making a release and looking into new features. > > > > Yes, the same was noted about a year ago from our side, where the > > development model used at that time was leading to unproductivity in > > the development of JChemPaint (the one using SWT widgets). > > > > This lead to a changed development model, and I am sorry to hear that > > this second iteration of development model is not working either. I am > > even more sorry to hear that you do not even see options anymore is > > attempting a third iteration and that you feel a fork is inevitable. > > > >> We will of course follow the development of the CDK renderer/controller > >> packages and port new developments from time to time. > > > > Collaboration is never easy, and it is a shame that JChemPaint 3.0 > > (now in two forks) is now no longer "Using the Collaborative Forces of > > the Internet" as did the first version. > > > >> This JCP repository compiles with cdk master. We also made some patches > >> outside renderer/controller, these have been filed as patches. Since we > >> want to release JCP 3.0 asap based on the svn repository and master, we > >> would like to see these applied (could we ask cdk developers to have a > >> look at them?) > > > > This brings as to a more serious problem of this fork. There now are > > two JChemPaint forks, both of which require patches in the CDK. I have > > reworked some of Gilleain, Stefans and my original patches in > > JChemPaint-Primary, which I am not sure are picked up by > > JChemPaint-EBI. Either case, it seems that both versions of things are > > now up to review by CDK developers... (the jchempaint-primary versions > > of those required CDK patches are listed in the 0-other branch at [0] > > and also filed in the CDK patch system for review). > > > > Christoph, I strongly suggest we work out at least these required CDK > > patches between your and our team, and do not require other CDK > > developers to get too deeply involved in issues resulting from this > > fork. > > > > Egon > > > > 0.http://pele.farmbio.uu.se/cgi-bin/gitweb.cgi?p=jchempaint-primary.git;a > >=shortlog;h=refs/heads/0-other > > > > -- > > Post-doc @ Uppsala University > > Homepage: http://egonw.github.com/ > > Blog: http://chem-bla-ics.blogspot.com/ > > PubList: http://www.citeulike.org/user/egonw/tag/papers > > > > ------------------------------------------------------------------------- > >----- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > > 30-Day trial. Simplify your report design, integration and deployment - > > and focus on what you do best, core application coding. Discover what's > > new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Cdk-devel mailing list > > Cdk...@li... > > https://lists.sourceforge.net/lists/listinfo/cdk-devel > > --------------------------------------------------------------------------- >--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment - and > focus on what you do best, core application coding. Discover what's new > with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel -- 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: Egon W. <ego...@gm...> - 2009-11-30 11:15:46
|
On Mon, Nov 30, 2009 at 11:53 AM, Stefan Kuhn <ste...@eb...> wrote: > I think there are two issues here: > 1. Why have two repositories? Well the reason is it was decided by the > community not to have jcp in cdk. To complement: the JChemPaint *application* code is not in the CDK library. The renderer and editing functionality is. The *application* code is not library code, and, for example, widget set depending. (application := referring to wrapping GUI code, so including applets, javascript translations, GWTs, SWT wrappers, ...) >> that hasn't been touched in 4 months. That >> makes this an unlikely candidate for the repo for the most active branch of >> the project... > > This has been moved to GIT, but JCP is using master now. I will remove that SVN branch. >> One final gripey question about the current state of the repos is "why so >> many rebases for egonw's commits?" rebase is one of those features of git >> that I try to avoid using. When I see this sort of thing it suggests to me >> that there was probably a better way to achieve the same ends. But, then >> again, I don't really understand the relationship between, say, egonw's >> changes and jcp-primary. > > I can't comment on that, please let Egonw explain this to you. Rebasing is the git way of automatically updating the patches for changes for code you depend on. The alternative is to manually rewrite those patches, which practically can be needed (and often is the case), when git cannot resolve the differences automatically. If you have ever took 100+ patches written for tool X version Y and tried to apply them to version Z (with API changes) of tool X, you'll start to appreciate rebasing. >> SUGGESTION 4: Lose the jchempaint-primary name. It's rather confusing to > > This is actually lost. What has? > I think we should delete the jcp-primary branch from > svn. I see no reason not to do that. Egonw, what do you think? Yes, see above. It was kept around for a while until I was 100% sure we had everything in git, but I forgot to remove that jchempaint-primary branch in SVN later ... Regarding the 'jchempaint-primary' name... it has a long history and should be replaced, and I am open to suggestions. If none show up, I'll convert it to 'cdk-jchempaint', like the mailing list. >> I hope this doesn't all come across as too much whiney complaining from a >> lurker, but I thought it might help to hear how the project(s) look(s) to >> someone from the outside. I have high hopes for CDK, but I'd rather see >> developers' energy go into things like proper SMILES parsing and 2-d >> rendering of geometric isomers, to single out a feature that prevents me >> from using any version of CDK for real work at the moment, than sorting out >> the various repo/fork issues. >> >> I think it's neither surprising nor necessarily bad that folks want to have >> different applets/applications that use CDK, even for similar purposes. >> What would be nice would be to continue factor shared components out of >> these. If the EBI group wants their own visualization app, great, but let's >> make sure the underlying foundations are solid. > > I can only share this view. But in order to do that sharing we need a working > development setup. We have had two development models for the new JChemPaint architecture now. One involved SVN which did not work for the Uppsala team, one which involved Git which does not work for the EBI team. Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Stefan K. <ste...@eb...> - 2009-11-30 11:25:04
|
On Monday 30 November 2009 10:59:51 you wrote: > On Mon, Nov 30, 2009 at 11:28 AM, Stefan Kuhn <ste...@eb...> wrote: > >> A snapshot was taken, from which things were further developed. That's > >> a branch to me. The fork did not happen until this weekend. > > > > What snapshot are you talking about? We did a clone of your repository, > > which we rebased frequently and worked on that. Where is the snapshot? > > Like you say, a snapshot := a certain git commit. So you are saying the snapshots are inherent with GIT? In your email from 29 November 2009 16:08:27 you wrote: "Patches in those two packages are actually not difficult because of needed review. Those patches are not really reviewed at all yet; instead, it's the fact that things were already somewhat forked, as both JChemPaint-SWT and JChemPaint-Swing used snapshots of renderer and controller module." This, for my understanding, means that the usage of what you call snapshots makes it difficult. Taking into account that you say that snapshots are inherent with GIT, you say, applying rules of logic, that GIT makes development difficult. Thanks for clarifying this Stefan -- 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: Egon W. <ego...@gm...> - 2009-11-30 11:36:33
|
On Mon, Nov 30, 2009 at 12:24 PM, Stefan Kuhn <ste...@eb...> wrote: > On Monday 30 November 2009 10:59:51 you wrote: > So you are saying the snapshots are inherent with GIT? Like with *any* version control system. Feel free to read 'commit' whenever I say snapshot. You work against a certain API, say that of CDK 1.3.0. You do that for a while, because you like to release an version of your GUI, say Bioclipse 2.0 or a JChemPaint applet. You stick to that version for a while, and make a 'snaphot' of the libraries you are using. Nothing special about git here. > In your email from 29 > November 2009 16:08:27 you wrote: > "Patches in those two packages are actually not difficult because of > needed review. Those patches are not really reviewed at all yet; > instead, it's the fact that things were already somewhat forked, as > both JChemPaint-SWT and JChemPaint-Swing used snapshots of renderer > and controller module." > > This, for my understanding, means that the usage of what you call snapshots > makes it difficult. Of course it does. Using a changed API for any library is difficult. Using a patches version of any library is difficult. Using commit SVN+3 is difficult: it changed behavior, and you have to compensate for that. > Taking into account that you say that snapshots are > inherent with GIT, you say, applying rules of logic, that GIT makes > development difficult. No. That is your conclusion. The problems of keeping up with a moving target has nothing to do with git. > Thanks for clarifying this I am not sure what I just clarified, but it is not that I think that git makes things difficult (I think quite the opposite). Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Egon W. <ego...@gm...> - 2009-11-30 11:58:41
|
On Mon, Nov 30, 2009 at 12:15 PM, Egon Willighagen <ego...@gm...> wrote: > We have had two development models for the new JChemPaint architecture > now. One involved SVN which did not work for the Uppsala team, one > which involved Git which does not work for the EBI team. I have to correct this: the first solution was not working for the EBI team either. Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Stefan K. <ste...@eb...> - 2009-11-30 12:02:27
|
On Monday 30 November 2009 11:58:08 Egon Willighagen wrote: > On Mon, Nov 30, 2009 at 12:15 PM, Egon Willighagen > > <ego...@gm...> wrote: > > We have had two development models for the new JChemPaint architecture > > now. One involved SVN which did not work for the Uppsala team, one > > which involved Git which does not work for the EBI team. > > I have to correct this: the first solution was not working for the EBI > team either. I didn't know it did not work for me, great you tell me. Stefan > > Egon -- 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: Egon W. <ego...@gm...> - 2009-11-30 12:10:48
|
On Mon, Nov 30, 2009 at 1:02 PM, Stefan Kuhn <ste...@eb...> wrote: > On Monday 30 November 2009 11:58:08 Egon Willighagen wrote: >> I have to correct this: the first solution was not working for the EBI >> team either. > > I didn't know it did not work for me, great you tell me. It must have been someone else who wanted less API refactoring. My apologies for ascribing that quote to the EBI team and effectively to you and Gilleain. I should have kept factual and mentioned the observation that also in the SVN world we had branching, and smaller and larger changes and that then too, a single monolitic repository was not working. I am still positive that it was not just me who noticed that that did not work efficiently. Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Jonathan A. <jon...@gm...> - 2009-11-30 12:38:40
|
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? -- // Jonathan |
From: Stefan K. <ste...@eb...> - 2009-11-30 21:53:06
|
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: Cyrus H. <ch...@bo...> - 2009-11-30 15:26:25
|
On Nov 30, 2009, at 3:15 AM, Egon Willighagen wrote: > We have had two development models for the new JChemPaint architecture > now. One involved SVN which did not work for the Uppsala team, one > which involved Git which does not work for the EBI team. Sounds like a recipe for disaster. Why can't git work for the EBI team? thanks, cyrus |
From: Stefan K. <ste...@eb...> - 2009-11-30 15:39:09
|
I have written an email to the mailing liste hours ago about exactly this. Once it gets throught please read it. In short, the problem is not git or svn or whatever, the problem is not working on a common codebase. If our patches would get into git, there would be not problem with git. But if our patches are not applied for months, no matter if in git or any other repository, it becomes a chaos. Fullstop. Stefan On Monday 30 November 2009 15:26:13 Cyrus Harmon wrote: > On Nov 30, 2009, at 3:15 AM, Egon Willighagen wrote: > > We have had two development models for the new JChemPaint architecture > > now. One involved SVN which did not work for the Uppsala team, one > > which involved Git which does not work for the EBI team. > > Sounds like a recipe for disaster. Why can't git work for the EBI team? > > thanks, > > cyrus -- 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 |