Date: Wed, 21 Jan 2009 16:45:54 +0100
From: Edward d'Auvergne <edward@xxxxxxxxxxxxx>
To: Petr Novak <shaman@xxxxxxxxxxxxxxxxxx>,
Pavel Kaderavek <kada@xxxxxxxxxxxxx>
Cc: relax-devel@xxxxxxx
Subject: Re: cst branch development
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
Re: cst branch development