The development team is discussing the possibility of a 2.2-alpha2 release next week. This revision would attempt to address some of the problems reported by testers running through the upgrade process. (Many thanks to Thomas Berezansky for creating a script that automates most of the release process for 2.1 and subsequent release series - better living through automation!)

There are a number of outstanding bugs that have been fixed in the 2.0 release series that justify a 2.0.11 release, but as the release process is almost entirely manual for the 2.0 release series, we have a lack of skilled people with the time to create this release.

Anoop Aatre posted a draft "End of Life" policy to the Development mailing list concerning community support for Evergreen releases. He requested a vote for the policy in principle as well as for suggestions for any further wording adjustment.

The development team is attempting to maintain a high degree of quality by ensuring that all code is reviewed and signed off by at least one other contributor before being committed. As a testimonial to master's quality, some developers advocate running Evergreen straight from master (as the Merrimack Valley Library Consortium does). However, the development team is now struggling with a large backlog of requests for review, sign-off, and commits; testing and reviewing code currently takes a lot of manual effort. The weekly activity graph illustrates that our commit pace has tailed off, while the bugs with requests for merging are currently up to 39.

(At this point, dbs devolves into asserting for the umpteenth time that an automated test suite with realistic sample data and broad functional coverage, along with the requirement that branches include test cases to cover the conditions they are addressing, would help prevent future backlogs while improving codebase quality. However, the development team currently lacks a good set of sample templates for regression tests and that is one possible inhibitor for making significant progress on that front.)

The structure of the development team includes:

• Evergreen bug wranglers - people who report bugs and test suggested code
• Evergreen drivers - bug wranglers who have the ability to target bugs to specific releases
• Evergreen release team - committers plus chief bug wrangler (Jason Stephenson)
• Evergreen security team - release team + members of the community with a demonstrated understanding of how to address security vulnerabilities