Open caseyjlaw opened 2 years ago
repo: dsa110-pyutils origin/development and origin/cjl/dev have already merged work based off of v3.7.0-rc1 There are a few branches which have not been merged. Are they still under development? origin/calibration (Dana), origin/dsastorag (dsa-storage-user) and origin/noavg (dsa-storage-user). Diffs between v3.7.0-rc1 and origin/development( e684ff2) look to be all backward compatible except: def get_DM(mjd, ibeam, full): where 'full' has been added. If this is given a default value, then it will be backward compatible. Its use is only for I/O so this seems worth doing. We can then tag (e684ff2) v3.8.0-rc1 and test. If successful, merge onto master branch and tag v3.8.0
I think the other branches do not need to be merged. I saw the development branch get_DM
function did have a default for that function, so I think it was fine.
I merged development into master and tagged it v3.8.0-rc1. Could you take a look and tag it 'v3.8.0' if you are happy?
It would be great to get this all into myrepos.
In cli.py the following 2 functions have been defined, then redefined:
def snap(snapnum) def snap(snapnum, prop, val): def corr(command): def corr():
It's unclear what the decorators, mon.command and con.command are doing so it's possible this is ok but it doesn't play nice with pylint.
I'm also not getting unit tests to pass but maybe my env.
Ah, yes. The decorators define the way the command-line tools are created. These are different tools to either monitor or command the snaps, so the names are appropriate.
are you passing unit tests in dsautils?
I found some cnf tests failing after updates to services over the last few months. That's all updated in development branch and passing for me now.
I see a warning AttributeError: 'SysLogHandler' object has no attribute 'socket'
. Is that a known issue we can leave for now?
yes. I'm not sure what is going on in dsa110-shell. I see a lot of 3.0.0-rcXXX tags but they seemed to have blown by a 3.1.0-rc1 tag. I would normally update the .mrconfig_production with all the rc tags, test, then label all the rc tags with non rc(ie. v3.8.0-rc1 -> v3.8.0 and then update .mrconfig_production. There's no churn on tagging so should be safe.
I sent an email, but I know Rick prefers to do this properly, so... I am now happy with calling these tagged versions ready:
There is a release candidate for dsautils. Ideally, you would merge that into main, then try to merge and tag my changes on top of that. After all that, let’s check in with Vikram on a good time to test deployment.