Thread Previous • Date Previous • Date Next • Thread Next |
On 15/12/2010, at 20.49, Tim Fenn wrote:
At the moment, you are in fact able to push changes directly on the bzr branch of MMDB and SSM, because the two branches lp:mmdb and lp:ssm are owned by the structbiol team. The gpp4 branch lp:gpp4 is currently not, because it was created before the team existed.OK - I'm just not sure what the proper format for bzr push to use? I tried one or two things without success, could you give me a hint?
To push directly to the project branch: bzr push --remember lp:mmdb(that swich will set the "push" location, so you can do "bzr push" the next time)
The way to propagate changes to a project that you don't own and can't push to is to create a branch of the project on launchpad, and push your changes to that branch. You can then request the project owner to merge your branch into the main branch.I did that with all three, just for practice. >.<
I don't see merge requests on LP? I can see that you have pushed the code to "+junk" branches, but I am not sure if you can file a merge request on those?
There are some significant recent changes on the MMDB code. All patches from the Coot dependencies distribution (1.23.2) have now been merged into the launchpad MMDB project, and the code was released as version 1.23.2.1. In addition, there are some quite significant bug-fixes. Most are latent bugs, where variables are initialized inside a conditional statement, but referenced outside. These bugs will hit only if the conditional is not fullfilled (which may be never). The most serious bug prevents the rwbrook Fortran bindings from ever dealing with atomic displacement tensors in fractional form, see [0].Ah, OK - I was wondering about the odd versioning there. Which brings up another point: we're following upstream, but adding fixes/edits to the code - maybe we should stick with the upstream version numbering/files and include our changes as a patch set that can be applied before building, to avoid confusion and potential conflicts/problems? The patches could be sent upstream. Or we couldhave our own, independent naming/versioning scheme, (like what was done with gpp4 - for example, gmmdb and gssm or something) - that way peoplewho download the code know/realize its not the "official" ccp4 stuff. We also mentioned following the CCP4 numbering scheme, e.g. it appearsthat ccp4 6.1.24 is the latest release. Is the plan to match that withthe gpp4/mmdb/ssm versioning?
I am kinda on the fence on this. As I wrote earlier, I had an email exchange with Eugene Krissinel, and he told me that mmdb would be distributed only as a part of the CCP4 distribution in the future. However, I was surprised to discover that the version of mmdb that is distributed as an dependency of Coot seems to be much newer than the version that came with CCP4 6.1.13. My feeling is that the CCP4 people are not being very cooperative, and perhaps even annoyed that their software is being distributed as standalone versions.
For mmdb, I chose to stick to the 1.23.2.* versioning scheme, since that is the closest "official" release. However, there are some extra patches applied to that branch, which is why I added the fourth version number. I considered something like 1.23.2p* but ultimately it doesn't matter I think.
I think our patches should be contributed back, however, there is a bit of work involved and I have not had time to work on that yet.
We also mentioned following the CCP4 numbering scheme, e.g. it appearsthat ccp4 6.1.24 is the latest release. Is the plan to match that withthe gpp4/mmdb/ssm versioning?
Adopting the CCP4 numbering scheme for will introduce the same problems, and when the upstream maintainers are not cooperating, it becomes quite difficult, because nothing prevents them from using the version numbers we are using.
With gpp4 I have introduced all/most changes from 6.1.24, these changes are already in trunk (but not released yet, as I have not yet had a chance to test it). There are fundemental changes to the low level map and mtz reading routines.
Cheers, Morten
Thread Previous • Date Previous • Date Next • Thread Next |