Discussion arround: First draft for MEP-01 #615

[marcus-oscarsson]

Comments on PR #615 from @jordiandreu, the actual document can be found here.

[marcus-oscarsson]

This was just an attempt to investigate if this would be a good "forum" for discussing a MEP, and I used the draft MEP-01 as an example. I'am somewhat hesittant that the moment, what does the rest of you think ?. We can maybe discuss this on our next meeting.

[rhfogh]

MEP-01 looks really good. It uses existing procedures, and it is clearly defined what should happen, so we can make sure we follow it.

I do think we need to agree on some use cases. We have the special problem of there being many different 'live' branches at different synchrotrons, which we will need to deal with clearly.

Let us assume that the main branch is at 1.3.3, and Synchrotron X is still working off main branch 1.1.5.

• What should be the branch tag for Synchrotron X production code?

• If Synchrotron X wants to make a site-specific change, e.g. adding new hardware, what branch do they make to work in, and where do they merge it back?

• If Synchrotron X wants to make a generally useful change, e.g. developing a new centring method, what branch do they make to work in, and where do they merge it back?

• If a third party (say, myself) wants to develop for synchrotron Y (at branch 1.2.2) and then move the result to Synchrotron X (at 1.1.5) and the main development branch (ahead of 1.3.3), what should the branching structure be?

[marcus-oscarsson]

I'm not certain that I understood your questions completely, but this is what I understood from our last dicussions

Let us assume that the main branch is at 1.3.3, and Synchrotron X is still working off main branch 1.1.5.

* What should be the branch tag for Synchrotron X production code?

There is not branch or tag dedicated specifically to Synchrotron X production code , Synchrotron X would be
on version 1.1.5, they would be on tag 1.1.5

* If Synchrotron X wants to make a site-specific change, e.g. adding new hardware, what branch do they make to work in, and where do they merge it back?

I think we said that site specific changes would not be included in this schema so they would still be on 1.1.5, right ?

* If Synchrotron X wants to make a generally useful change, e.g. developing a new centring method, what branch do they make to work in, and where do they merge it back?

I would say that it would be preferable if the change is made to work on the latest stable version as well as on whatever version
Synchrotron X currently is on (in your example 1.1.5) and to be ported to 1.3.3 (if possible)

* If a third party (say, myself) wants to develop for synchrotron Y (at branch 1.2.2) and then move the result to Synchrotron X (at 1.1.5) and the main development branch (ahead of 1.3.3), what should the branching structure be?

You would need to make sure that your feature is API compatible with both 1.2.2 and 1.1.5 or make changes so that the functionality is maintained and the API of both 1.2.2, 1.1.5 is respectively respected. It would also be preferable if this
feature was ported to the latest stable version

[rhfogh]

Hmm. In more general terms, the problem is that the schema presented by Jordi assumes that all development is happening at the tip. The only alternative feature is hotfixes, and that is specifically limited to bug fixes. If I understand you right, you are saying that this is a feature - anything that happens on releases older than the most recent one is and should be invisible outside the synchrotron itself. In real life, however, a lot of development is likely to be happening in side branches. In practice, is synchrotron X going to be 'on version 1.1.5' in the sense that a program that conforms to the 1.1.5 API can be slotted in and expected to run straight away? Or is it going to be 'on 1.1.5' much the way that COVID-19 is a disease of bats - it was once, but it has changed quite a lot since then?

The system as described in the MEP has no mechanisms to keep older versions in sync as they change, and no mechanisms to move site-specific code back to the main development branch - except when sites update to the latest release. Just for illustration, I am currently trying to port my latest workflow version from P14-production to PX2 production. As always, the underlying versions have diverged so far that it is in practice impossible to do any kind of repository operation to make the move. Hence I am porting my code to the new branch by hand-editing and gdiff, losing any kind of history and introducing bugs that I then need to fix.

It would be great if in the future there was some kind of support that would make this kind of synchronisation easier - as well as making it easier for the synchrotrons to upgrade to newer versions. What do you see that looks promising?

[marcus-oscarsson]

Hmm. In more general terms, the problem is that the schema presented by Jordi assumes that all development is happening at the tip.

I see, I kind of understood it as its allowed to have a dev branch for i.e 1.1.x where development relevant for 1.1 can continue.

The only alternative feature is hotfixes, and that is specifically limited to bug fixes. If I understand you right, you are saying that this is a feature - anything that happens on releases older than the most recent one is and should be invisible outside the synchrotron itself.

That's not really what I meant at least. But its true that ongoing development is not something that we usually keep in a publicly available branch (some times in a fork). So what you would like is that all ongoing development is publicly available and kept up to date ?

In real life, however, a lot of development is likely to be happening in side branches. In practice, is synchrotron X going to be 'on version 1.1.5' in the sense that a program that conforms to the 1.1.5 API can be slotted in and expected to run straight away?
Or is it going to be 'on 1.1.5' much the way that COVID-19 is a disease of bats - it was once, but it has changed quite a lot since then?

Not sure that I really understood this, but yeas a program that relies on the API defined in version 1.1.5 should of course work with a installation that uses mxcubecore 1.1.5. The site specific changes needs to comply with 1.1.5. There can of course be (and will be) local changes but that should be fine as long as they are also compatible with 1.1.5. The development can continue on the branch 1.1.x (or 1.1-dev) that eventually needs to be merged back to create a new 1.1.6 (or whatever) release. These changes should then (in my opinion) also be ported to the latest dev branch.

The system as described in the MEP has no mechanisms to keep older versions in sync as they change, and no mechanisms to move site-specific code back to the main development branch - except when sites update to the latest release. Just for illustration, I am currently trying to port my latest workflow version from P14-production to PX2 production. As always, the underlying versions have diverged so far that it is in practice impossible to do any kind of repository operation to make the move. Hence I am porting my code to the new branch by hand-editing and gdiff, losing any kind of history and introducing bugs that I then need to fix.

The site specific code should be a client of the API defined by mxcubecore so merging site specific code back should not break the API. There might be site specific additions not part of the common API but that's something else.

I guess the problem you are having is that the code on P14 and PX2 have not been mreged in a long time and cant be considered to conform to the same API ?

It would be great if in the future there was some kind of support that would make this kind of synchronisation easier - as well as making it easier for the synchrotrons to upgrade to newer versions. What do you see that looks promising?

I think we somehow outlined this during our last meeting. Keeping the source up to date will always require some effort and more often its done (the smaller the changes) the easier it gets. Our current suggestion puts in to place regular meetings were the changes are discussed and the new versions are crated. This makes it easier to follow the changes and to adapt them in smaller chunks. It also forces us to merge code more often as these meetings are kept with a regular interval. I think that would be the main benefit from this, we can perhaps come up with a different way of handling this in Git if what we have today or what Jordi proposed is not good enough.

[rhfogh]

Actually, I was not quite sure what I wanted done - only what I wanted solved. But I like what you are saying. Can I summarise?

• Synchrotrons are responsible to conform to the API of the version they say they are using, or to say clearly when they do not.

• The repository should have dev side branches, one for each release, and synchrotrons should be encouraged to commit local changes back to the side branches (at least). NB Maybe we should either limit the number of releases, or agree on growing only a subset of them as side branches.

• I would propose that we should (encourage people to? insist on?) at least opening a mock version when they check in something, as well as testing it on their own beamline.

I think it might be good to get all this explicit - as you see I had not understood it properly - so we can first agree on realistic requirements, and second push for people sticking to them.

[marcus-oscarsson]

:), That's a quite good summary 👍

I'm certain some of the others have some improvements on this or some other good ideas to add. I completely agree that we don't want to many parallel side branches, its one of the risks I see with this proposal.

I agree that we also need to improve the routines for testing for this to work better

We can maybe try to conclude this during our next developers meeting and then in the meantime continue the discussion here ?