Attending: Oliver, Chris, Paul, Kathy, Ernest
- Any objections to last week's summary?
Kathy noted that the build transition should be complete in the next few weeks but Intel should continue to have cron job
- Chris mentioned that this was discussed by email and is on track.
Candidate build was declared yesterday
- 1 week test pass is starting now and will finish next tuesday
- From here on out, only critical defects will be promoted to 4.6.2
Oliver asked if we know how the test pass is going
- folks just started yesterday. It will be a few days before we can check progress.
- Paul notes reports are open for checkin of results. He will verify if BVTs results are getting captured.
We now have split stream. Head is for 4.7 development
- Had a build break yesterday but is resolved.
Oliver and Chris reiterated the outcome of a discussion that Oliver had with Intel management on Monday.
- Intel's resourcing in TPTP will end around the 4.6.2 release and will not continue into the 4.7 release.
- After around mid Feb, the Intel team will not provide any additional engineering. We do expect that there will be some questions that come up after the transition that the Intel team can hopefully answer from their residual knowledge.
- This announcement was expected based on discussions that have happened over the last few months.
- We discussed the impact of this on TPTP.
- Over next week, Kathy will triage buglist currently tagged as 4.7 to identify if there are a few specific bugs where IBM needs additional input from Intel.
- Except for defects to be discussed, plan from Intel is that after the 3rd week of Feb, Intel will be down to answering "reasonable" questions.
We discussed the mail thread about reorganizing the components and removing/depracating some features. Chris' major question was whether we needed to go to TPTP 5 in order to do what we are trying to do.
- Paul notes that the last major change TPTP 3 to TPTP 4 was from hyades to tptp.
- 3.x to 4 changed "a ton" of APIs
- Paul is unsure if the restructuring that we are doing really justifies a major change
- We compared the TPTP API contract document to the overall Eclipse API contract.
- The Eclipse contract states "breaking" changes require a new major release.
- For components that we are changing, are there a lot of extension points. Most was provisional or tech preview but some are GA.
- tech preview stuff is okay to kill without making a breaking change but the GA is a grey area. By some readings they are "breaking" changes.
IBM noted that consumers currently don't have a problem with keeping 4.7 and understand what is getting deprecated.
We made similar changes/deprecations in both TPTP 4.5 and TPTP 4.6. It is definately possible that we might have broken the contract in those releases.
There is general agreement that these changes are not major components and the PMC would like to be consistent with what we did in 4.5 and 4.6 and just name this 4.7.
We discussed the best way to resolve the conflict between what we want to do and the API contract document. Chris suggested that we tweak the API contract wording to cover "significant" API change as requiring a major revision. In this way, the PMC can interpret, with input from the community, if an API change should be considered breaking and require a major release.
There was general approval of this and we voted on it. New paragraph:
- For example, any "significant" public API that existed in the X.0.0 release will be maintained throughout any maintenance release of X.0, such as X.0.1, X.1, or X.1.1. If TPTP does intend to break an api then TPTP deprecates for a full major release first.
- The proposal was unanimously approved
Oliver asks if there is update regarding EclipseCon
- IBM has no update yet. There were ~5 talk submissions from IBM. Need to see the acceptance and follow thru to see if travel funding canhappen
- It looks like IBM gets talks accepted and if there are other technical discussion topics (like project shutdown dialogue) there might be enough travel justification
- The timeline details from Intel that we now know should help trigger more of this discussion inside of IBM.