← Back to team overview

structbiol team mailing list archive

Re: a few changes

 


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 could
have our own, independent naming/versioning scheme, (like what was done with gpp4 - for example, gmmdb and gssm or something) - that way people
who download the code know/realize its not the "official" ccp4 stuff.
We also mentioned following the CCP4 numbering scheme, e.g. it appears
that ccp4 6.1.24 is the latest release. Is the plan to match that with
the 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 appears
that ccp4 6.1.24 is the latest release. Is the plan to match that with
the 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




Follow ups

References