COSMOSCommunityMeeting20081210

Att: Jason Saurabh David Ruth

Candidate build

• candidate build? Build is failing with an error. Dependency on TPTP for the BTG. Josh is going to refactor the tests and move them out. He's supposed to have that done today before 5. Can we spin a build at 5 today? He should be done before then, he will send email if that's not the case, we shouldn't try to spin the build if we know that it will fail.
• iteration candidate build made on Wed, not Friday. By Wed we would have gone through the JUnits. We try not to go much more than a day of validating the integration build.
• need to have someone from SDD run a sanity test on the candidate builds
• typically the weekly integration build testing was just to ensure that everything was hanging together.
• good practice for every developer to take the weekly candidate build and test that everything that they've checked in during the week is good to go
• a reminder, the goal of the iteration test pass is to try and make whereas weekly is to work out kinks and produce something for us internally, the iteration test pass is to make something that is stable enough to adopt should someone want to proactively pick it up. It's not a milestone, which is advertised by us, but it should be stable. Should be stable, not as functionally complete as a milestone, not advertised by us, but should be stable enough to get feedback from developers on it.
• every developer should pick up the iteration candidate driver and do whatever tests that they think are necessary to ensure that it's ready for the full fledged test pass
• when you need to split the work across iterations, should use bite size pieces that are complete at the end of an iteration
• everything for this iteration will be complete at the end of this iteration

Iteration 1

• cross component should be in the COSMOS dev process, not necessarily a work item for an iteration
• the API work item should be at the milestone boundary, not every iteration. API defined as documented, package names, etc.
• in each iteration, we want to ensure that we're not calling something that is not intended to be API. Could be enforced by the build? Eclipse plugins yes, DOJO & SDD no.
• when each subteam reports on the sanity test for the iteration candidate, also report on that everything has been externalized/internationalized, logging consistent, not calling anything that isn't intended to be API

• what enhancements are RE planning to do? related to the SDD work automating the JUnits. Saurabh to enter that into the table so that we can track this.
• Ruth to clean up the "mandatory for releasing V1.1" section to show the iteration deliverables
• IP log and about.html should be reported on per iteration
• release review slides, inactive committer list should be reported on the GA - 1 iteration due to needing to be submitted in advance
• will remove the Mandatory for releasing V1.1 and instead open bugzillas and add them to the table to make it easier to track

Eclipse IP process

• IP poster is overvigilant, inconsistent with the other Eclipse Legal process
• statement at the top of the poster said, "all code must be reviewed by the PMC" but there's conditions to that. Eclipse Legal will revise the poster to review the statement at the top.
• for simple bug fixes and minor enhancements, PMC and EMO approval is not required
• for a sizeable piece of work, regardless of fix or enhancement, need PMC approval. Is that true for anything that we contribute, or only contributions by non-committers?
• also a distinction about non-committers who are part of a strategic member and work for the same employer
• Brad Beck, CA, will be a committer but paperwork not done yet. If the iteration will be destabilized by not having this code, then ask PMC. Otherwise can wait until Iteration 2. Have him zip up the patch, attach it to bugzilla, get PMC approval, mark it iplog+
• David to post the rest of his questions on the 256789 bugzilla