AGENDA

  1. Sorting out Java rc1
  2. Other 4.4 release matters

MINUTES:

Attendees: AJ, GS, MK, MS, GW, DH

Scribe: AJ

Chair: GW

Java rc1

GW: Looking at Release Tracker, URL =

https://docs.google.com/spreadsheets/d/16vIVdopCigfDA7VfepEg4aaKGPqp0n8uIydGIRJpbpg/edit#gid=0

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

MS: OK.

GW We still have a dependency on Java 1.7

Ok. meeting closed 10:57 CST.