Attendees: AJ, GS, MK, MS, GW, DH
GW: Looking at Release Tracker, URL =
… is a bit messed up.
Prepare entries for rc2 with Marty’s new tags, adjust the rc1 tags back to what they were/should be.
MK: Ralph did change his entries.
GW: He changed dependencies, has he re-tagged?
MK: I think so.
MS: 2 hours ago he updated the POM with latest pvAccess, pvData and changed his tag.
GW: He didn’t have a chance to test.
MS: C++ is relaxed, unlike Java where the changes have to be done in order to be reflected in dependent modules.
GW: Intended that setting column I to Yes should lock your changes for this row.
MS: Could we do that with a spreadsheet macro.
GW: This group both likes & hates formalized procedures
AJ: Different members…
MK: My fault, I fixed a couple of bugs..
GW: Should be package Java rc1 with what the module tracker says?
MK, MS: Yes
GW: Will do this immediately after the meeting.
MK: You’re going to update the tag and POM for exampleJava?
GW: I guess so, but something seems wrong.
AJ: POM is in the repository, so you have to come out with a new version when only the dependencies change.
GW: Is there POM syntax that would allow later versions to be used, as long as version number is “compatible”?
MS: You can, including meta-regexp’s. I agreee this is annoying, for things like exampleJava that would be good, but can’t do that for the core modules, behaviour is too closely linked.
AI on GW: Change exampleJava, then build and release the Java -rc1.
Topic development and release procedure
GW: Let’s tighten up the build procedure to explicitly say that setting column I to Yes should lock the whole row. We need a better release document, split up the current one into constant part and dynamic part. Better description on how to do development (using hg flow) and the mechanics of doing a release.
AJ: I’d rather that someone who does the development and release work change the release document.
GW: Ok, I will change the release document, add material on how to package Java, Dave can do C++. Need to add a tighter description so someone can follow instructions like a recipe.
DH: I can do C++ release doc portions.
GW: Dave and I will work on that, describe the mechanics in detail to save time every release.
GW: Then we’ll add a section on mechanics of development process - the hg flow commands and the regular hg commands for pushing and tagging etc.
MK: pvaPy is still Gray, I’ll make it black.
DH: I wasn’t sure what the correct procedure was - whether you had to ungrey the line in the spreadsheet if you didn’t want to make a change or you could leave it gray. I took it to mean pvaSrv was unchanged.
GW: I meant grey to mean “hasn’t been changed by the module owner yet”.
DH: OK. So our procedure is that Sinisa should have ungrayed, but left it otherwise unchanged?
GW: Release notes and documentation needs updating.
Documentation updates for 4.4
GW: Proposed updates to documentation for 4.4:
- doxygen and javadoc published and linked from literature.html
- gettingStarted updated
- README updated and moved into SF files area
- features list written
- architectures spreadsheet published to web page
GW: Does cloudbees publish the docs in a known URL that we can just link to?
MS: Builds head version, so will be overwritten when the next commit happens. Can be changed to make release branch copy docs to a permanent location.
GW: That’s what we want, every release branch should have a fixed URL with the latest docs from that branch published.
GW: Do we have much doxygen documentation?
MS: Only in headers, API is documented, I’ll have to check whether it’s generated and updated.
AI on MS: Send GW URLs of the permanent locations so I can update the webpage
DH: I started updating getting started guide for the C++ versions but didn’t finish. I’ll do that next (I’ve lost sound now by the way) .
GW: I will look at the rc1 README. Need a list of features; we had a couple of lists, where was Dave’s list?
DH: I put it in the updated readme. I thought greg said he was OK with it.
GW: Yes, can this just be moved into the files area of SourceForge?
DH: I guess so. Do you know how to do it? I looked it up before but I don’t remember.
GW: Yes, I know how to publish it. So I’ll do that.
DH: Can we also update the “looking for the latest version” too.
GW: I’ve tried to do that before. It seems to me one can’t explicitly change it!!
GW: If you can find a way, please make sure it points to the C++, or ideally both C++ and java.
DH: You must be because it says: Looking for the latest version? Download EPICS-CPP-4.3.0.tar.gz (5.5 MB). Why pick that version out. I think you can, but only one language.
GW: Yes, only one file. Can’t remember why it still says 4.3.
GW: Dave, can you make sure it now points to 4.4-rc1 c++?
AI: on DH, verify SF “latest version” points to 4.4
DH: OK. I’ll ask google.
MS: Or SF support.
DH: OK. But Google finds pages quite quickly. Usually better than sites search engines.
GW: OK, AIs on me and Matej. I will want to download and start using -rc1, then we decide whether to announce the -rc1 or wait for the full announcement.
GW: AJ, should we announce -rc1 to tech-talk? Inclination is not to.
AJ: Do you want feedback from outsiders? If not don’t bother.
GW: Ok we’ll try out -rc1 ourselves, only announce the final release.
AJ: pvaSrv is not compatible with the 3.14 IOC internal code
MS: The changes are trivial, can be done with ifdef’s. I can try and do that for -rc2
GW: We want to preserve compatibility with -rc2.
MK: Ralph should say whether he wants that or not.
MS: Some of that is in the security plugin.
GW: I would rather MS just makes those changes.
GW We still have a dependency on Java 1.7
Ok. meeting closed 10:57 CST.