Justin and Ben got through reviewing 10 tickets. 4 left to be committed ... still 2 requiring code changes, 1 will be punted to 1.7 release, and 1 more.
*Should have everything more or less ready to go by tomorrow, with alpha release expected end of next week. RC1 a month after that.
Patient-user refactoring needs to be submitted.
Ticket 1615___Add/Edit a Concept Rule - will not be added to 1.6, more design discussions are needed. Burke proposed treating this as a patch for 1.6 for the custom build for Kenya, and then try to get this into 1.7.
Discussion about logic module and how to test it. Who is using it?
Justin and Ben will be available for testing next week for the alpha release.
Next week, Monday and Tuesday will be code review, Wednesday commit the code, and Thursday testing.
Win will be setting up servers in Kenya at the end of the month (although they haven't arrived yet). Ideally, these can arrive with 1.6-alpha and the final release can be loaded on them by the end of the month when Win & Burke are together at the end of January/beginning of February. In theory, the new .war could be deployed after they leave, as long as things are running good at AMPATH in the pre-release versions.
Lesson learned: Ideally we can publish in advance dates for alpha, beta, and releases - allowing people to travel and be on-site at implementations when necessary. This will generally require more dedicated time from release managers and more development resources.
Discussion about the roles and responsibility of release manager.
Darius will work on an e-mail to go out soon preparing the community for 1.6 pre-releases so they can marshal resources for testing and evaluation.
Agenda item for 18 February: lessons learned from 1.6 release.
1.7 Release and beyond
What's in and what's out?
Several tickets in milestone OpenMRS Someday need to be moved to 1.7.
Some of the tickets punted out of 1.6 still need to be moved to 1.7.
We should be having the strategy discussion first. Burke: We need a process in place to prevent from endlessly "kicking the can down the street".
Maybe 1.7 should be a "catch-up" release for many of the tickets that have been deferred (but it shouldn't be overloaded and take a long time). 1.8 could focus on new features.
Rough, highly arbitrary ideas for timeline: 1.7 in April/May, 1.8 in September/October
As could be expected, 2.0 will represent some major changes in system design.
Where should reporting fit in to the release schedule? It's still in core at the API level, but was removed from the web layer. Paul suggested the new reporting framework be slated for 1.8 release.
Can the overall release planning process / roadmap be used for planning modules? Should there be "release managers" for modules? (e.g. Ben is working on the sync module.)