Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

TPTP-PMC-20090916

Logistics

Attending: Oliver, Chris, Paul, Eugene, Kathy

Any issues with last week's summary?

  • No

4.5.2 stream

Kathy noted bit of hiccup on M3 stream (a regression on linux) discovered by an adopting product

  • It was a build issue (similar to an issue seen in an earlier version)
    • Difference in gcc versions happened earlier in stream (wrong gcc used for one of the components)
    • We should take closer look at running regression tests on milestone drivers

This raised a general discussion about build reliability. We should think of addressing the problems more systematically rather than just restarting on failure sometimes.

4.6.1 stream

T test pass looks okay. Kathy proposes the deferral of two defects: 288001 and 215032.

  • These will moving to P1 for 4.6.2.
  • Move was unanimously approved

4.6.2/4.6.3 Schedule

We discussed Kathy's latest schedule draft that targets 4.6.2 for Feb winter maintenance and 4.6.3 for Helios.

  • She points out that Helios does have milestones before 4.6.2 finishes and wanted to discuss a bit more about our working mode.
    • We might have to split our work if there is a conflict (like EMF). By waiting to test with Helios, we raise the risk that we might have to respond quickly...

Two plans were suggested

  • Plan A drop Galileo based build to Helios after quick smoke test with Helios engine
  • Plan B build against Helios that has smoke test

We will probably do plan A initially then switch to plan B

  • Probably plan A for M3 (Nov). Maybe switch or keep plan A for M4 (Dec)
  • We should start by checking out Helios with some basic smoke testing and discuss switching if we need to

Kathy put up 4.6.2 schedule page draft and included helios drop dates for reference

  • There are 2 iterations in 4.6.2
  • Kathy's math accomodates a 2 week holiday cycle in December.
  • Chris noted that the holiday schedule in Beijing will not track to end of December. Chris noted the Oct 1-9 China holidays and Chinese new year (mid Feb next year)
  • Logically, the team should realize that Kathy's scheduled 2 week holidy cycle is a floating schedule based on team location.

The PMC noted that Kathy calendared 2 weeks of test pass for 4.6.2 I1 that overlaps with her calendaring of a 4.6.3 Helios test pass.

  • Eugene suggests doing a quick smoke test partway thru the I1 to reduce load during this overlapped test pass
  • Paul talked about formalizing some rampdown weeks where development is finishing and test pass starting up (smoke test) to also reduce load during this period.

Multisite Builds

There are some remaining issues with the cross site builds and the only reason they are cross site is because of Itanium builds at Intel. Paul raised the question of whether we should eliminate the IPF builds until the Itanium shipments to IBM happen

  • Chris thinks it is a bit premature to defeature Itanium and that we should try to evaluate the build problems
  • In general we would like to have the Beijing team able to check the nightly build before they leave for day.
    • Chris to start a discussion about what time the build at IBM should start to ensure this is possible.

We discussed Itanium transfer deadlines because Oliver was not able to attend last week. The PMC has decided

  • Nov 15th absolute final date for agreement on shipping the systems
  • Nov 30th absolute final date for arrival of systems at IBM
  • If these deadlines are not met, Itanium support will be removed in 4.6.2 and beyond.

Automated Test

Paul talked a bit about about reviving/expanding BVTs that automatically run on each build on several JVMs

  • Paul, Joel, Sean looked at assorted execution failures/test issues with BVTs.
  • They did some assorted cleanup of test code and it seems to be in good shape.

Paul would like to see committers doing more throrough job of making sure that their test code is clean.

  • Some of the latest issues came from a need to fix tests that had some issues.
  • Oliver asks if there is anything we need to more formally as a project to clean up or formalize how to do this type of things with our tests?
    • Historically Paul has fixed bad tests himself because it is expedient.
    • Paul will start to file defects instead to help leads point out issues they have with their test creation strategies.
    • Paul (and the rest of us I believe) hope leads will prioritize these defects highly.

Paul encourages committers to do as many tests via junit as possible. This will ensure that tests can be automated and thus have no ongoing execution cost.

  • If you already have junits that are not in BVT talk to Paul for logistics on how to get them added to BVT.

Paul thinks that the team will try to find some time to get junitplugin tests working with BVT.

Misc

Oliver gave a summary of the latest planning council discussions

Oliver asked if there has been any more traffic about OS/X(mac)?

  • After the initial patch submissions, there have not been more.
  • We probably need to post a build and more wiki content.

Back to the top