Hello all, I wish to offer myself to be the release manager for Evergreen 2.5. Since we have neither any guidelines nor any history of release manager proposals, I will try to outline in broad strokes how I would guide the development process.
A release cycle is fairly short, so I think a release manager might start by coordinating efforts around an idea which is simple, meaningful, and doable. In my case, I would like to tackle some of our lingering whitespace issues. To keep the scope to something reasonable, I would limit the efforts of this round to tab replacement only, and only in the Perl code. Second, to help manage both the whitespace transition and also the other parts of the roadmap, I would like to try splitting up the development period into smaller segments. While other terms would also work, for simplicity, we will generally call these "milestones". We would likely need just two additional breaks beyond the usual alpha/beta/RC schedule. I am thinking something along the lines of: June 1: 2.5-M1 (milestone 1) July 1: 2.5-M2 (milestone 2) August 1: 2.5-alpha August 15: 2.5-beta Sept. 1: 2.5-RC Sept. 15: 2.5 Final The first day of the months are general guidelines, not deadlines, and are chosen simply to be easy to remember (for instance, since June 1 is a Saturday, M1 likely wouldn't come out until the following Monday). Still, if 2.5 is to come out before the end of September, we only have two weeks of buffer space, so the schedule will be followed as tightly as possible. The milestones will be used in three ways: 1) All features on the roadmap will be targeted at one of the first three milestones (milestone 1 - alpha). It will be highly suggested (but not required) to split larger features into smaller distinct components which fit into a single milestone. Feature creators should plan to complete their work with enough time for testing and inclusion in the intended milestone. 2) Immediately following each milestone release, 1/3 of the Perl codebase will have their tabs replaced. The division will be announced well in advance of the first milestone, so that feature creators can suggest alternative division arrangements with the goal of minimizing potential conflicts with feature work. I will also attempt to develop and document best practices to work around any whitespace conflicts which do occur. 3) The above milestones will also serve as the primary communication schedule for the wider community. At each break, I will summarize what got in, what didn't, and what is planned for future. Finally, in complete contrast to the simple goal of whitespace cleanup, I would like for the community to make another run at improving some of the broad issues of Evergreen search. I am mentioning this last because I do not want this to be a primary focus of the 2.5 release, as that is likely a setup for failure. Nevertheless, like most hard problems, we would benefit from continually revisiting this issue in an iterative fashion, and I am interested in helping to foster discussion and organizing work toward any kind of improvement in this area. Thanks, Dan -- ********************************************************************************* Daniel Wells, Library Programmer Analyst d...@calvin.edu Hekman Library at Calvin College 616.526.7133
