On Wed, Jan 21, 2009 at 3:29 PM, Petr Novak <shaman@xxxxxxxxxxxxxxxxxx> wrote:
Hi, From your emails I got an impression that there are far more things to do/know than I expected (not only creating a functional code). The thing is that I understand the needs for all those but I simply might not have time to do it. My idea was that we would create a functional version of relax with features we want to implement, send you patch to check our changes and (dis)approve them and we would repair errors. I don't have enough time for sending couple of emails about each change we want to make and then coding it (reason given at the end) as it involves hundreds of codelines. So I would like to ask if you can see some solution. We see these possibilities on our side:
Hi. Yes, this development will be quite involved. The 1.3 line code is quite different from the 1.2 line code, so not much from your codebase (which was branched from the 1.2) can be used. The code in maths_fns/ should be fine, assuming it plays nicely with the rest of relax. Note that the process of getting this code in is peer reviewed, and anything which hurts other parts of relax or goes against relax's design principles will not be acceptable. The result is that only high quality, well designed code can get into relax. That being said, if you have mimicked other parts of the code base, then there may not be too many problems. But I do see this process taking 1 to 2 month to deliver to end users (but much longer for your citations to come in ;) Unfortunately a single patch covering all changes cannot be accepted. I need to check every line of code, and as this was developed in isolation, there is guaranteed to be a number of design issues. I need to ensure a consistent user interface throughout the program, that the coding style is consistent with the rest of relax, that there is no duplicated efforts, that historic links in the code are preserved, and that the code is of reasonable quality and bug-free. This is also the point of version control and working in a group environment. You code cannot step on the toes of other people code, and vice versa. It's a pity that the original code wasn't developed in public, or that the idea of forking relax wasn't discussed. That would have saved all these troubles. Nevertheless, we should be able to find a number of solutions.
1) we can give you the code for 1.2.10 - I think this is the worst option, because the code needs some work anyway and it would require conversion (btw tomorrow Pavel will link it anyway)
I think this can be done as a starting point. What I can do here is make a branch from the 1.2.10 tag in the subversion repository. You can then check out this tag and submit one massive patch (and any new files). I can incorporate this as one massive blob. Note that this code cannot be merged into the 1.2 line as this has been in feature freeze for 2 to 3 years now. Therefore it will serve as a historical note, and can be used by users as a last resort if no other solutions from below can be acheived.
2) we can give you 1.3 version of the files with equations - which means someone would have to write the code handling data to/from equations
This can be done as part of the cst branch anyway. The equations / number crunching code should be located in the maths_fns directory and, because of the abstraction layers, this code has not changed between relax versions 1.2 and 1.3. If this code comes from copying other code, then I must use the 'svn cp' command to create the files - no exception (for strong legal reasons).
3) we can give you 1.3 version of our implementation made without any serious preceding discussion about every detail of implementation - this would mean checking a rather big portion of code at one time and maybe somewhat more correspondence about repairing errors (which is no problem for me, I will be able to do minor thing once the major job is done)
This is not acceptable. This can never be done in an open source project. The same goes if you are working in a company developing non-public code as a group effort. Unless you are the sole author on a project, this just cannot ever be done.
4) after Pavel will return from Lund back to Czech republic (in approximately half a year) I can show him what to do and he will learn more about Python and do it whole himself. - this is very long shot so I don't think it is good plan.
If point 1 is undertaken, then someone else might decide to port this to the 1.3 line. Don't count on that though. For example I'm too busy as I'm still converting old code to the new 1.3 line design, I'm integrating relax with the BMRB, modifying the program to handle dynamically averaged NOEs, RDCs, PCSs, J-couplings, etc., porting 1.2 line code to make relax run on clusters and super-computers (Gary's code), and reviewing all changes that come in from other developers, especially the relaxation dispersion work of Seb. Therefore I won't have the time to port this code. Note that the 1.3 line has been specifically redesigned to better handle small molecules and RNA - it allows multiple spins per residue and different types of nuclei to be handled together. Therefore this will be much better for your analysis.
5) we can very roughly split our implementation into some logical parts and send it to relax-devel to discuss. We understand need of collaboration though again I am quite time-limited to discuss every line of every function before coding.
There is no need to discuss each line, especially if you just slightly change the behaviour of copied code (remember I will see and check every single line). But design decisions must be discussed. There are often times where the functionality you require is located in another part of the program, but you may not know it is there. This is quite a common situation, and I can therefore point you in the correct direction. Slightly expanding the abilities of current functions is preferable to reinventing the wheel. It's faster too. Oh, this development will take much longer than one or two weeks to have in a form deliverable to the end user. I would guess that a resonable estimate would be one month if all goes well, more if there are issues with clashes with the other parts of relax.
I would be very happy to have our analysis in the Relax project and I am definitly willing to work hard on it but currently I am very time-limited by the end of my PhD. What will be after I am done with studies I cannot predict because I don't have any post-doc position yet. It would be nice if we could find some solution. I am very sorry for these complications.
I would be happy to accept this code into relax, but this must be done in the proper way. Isolated development unknown to the main project developers is always a problem for merging the code back in. In most situations, this results in a fork of the parent project. But maintaining a fork is extremely expensive, time-wise, and therefore I would hope that we can manage to get this code ported to the 1.3 line and in a state that it can be merged into the main line. Then your code will benefit from any future developments that happen within relax, which for RNA will surely happen. Regards, Edward