structbiol team mailing list archive

[Tim Fenn <fenn@xxxxxxxxxxxx>]

On Sun, 19 Dec 2010 15:07:09 +0100
Morten Kjeldgaard <mok@xxxxxxxxxx> wrote:

> 
> 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)
> 

Ah, great - all set!

> >> 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?
> 

Ah, I found the info on how to do the merge requests (sorry, haven't
worked much on ubuntu before), would you prefer I do that in the future
or simply push directly to the main branch?

> >> 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.
> 

It seemed to me that Paul was modifying mmdb as needed for the
development arm of coot, and then contributed his changes back to
Eugene?

> 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 guess what I'm confused about is that the CCP4 release is the only
official release I know of now for mmdb/ssm, so where are the version
numbers coming from?

> 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.
> 

I agree - although I don't even know who to send this stuff to
anymore.  Eugene?

Regards,
-Tim

-- 
---------------------------------------------------------

        Tim Fenn
        fenn@xxxxxxxxxxxx
        Stanford University, School of Medicine
        James H. Clark Center
        318 Campus Drive, Room E300
        Stanford, CA  94305-5432
        Phone:  (650) 736-1714
        FAX:  (650) 736-1961

---------------------------------------------------------