Hello everyone, In my last communication, I indicated that 5/27 would be the suggested cutoff date for targeting bugs in Launchpad at Milestone 1 (2.5.0-m1). When I wrote that, I wasn't thinking about the fact that it was a U.S. holiday. So, everyone gets a one day extension, and today is the suggested cutoff for m1 targeted bugs. After today, please target any new 2.5 bugs/features at 2.5.0-m2. (One exception to this recommendation would be bugs deemed "High" or "Critical". Those should go in ASAP regardless of this process).
The reason for having this cutoff is that tomorrow begins the first commit push for 2.5 (and it can be demoralizing to try to tear down a mountain which is still building!). At current count we, have 63 tickets which have pullrequest tags and are apparently ready for merge. Since I am extending the assignment cutoff, we are also going to add a day to the commit period, which pushes the m1 commit cutoff to June 4 (end of day). If every committer handles one pullrequest ticket per day between now and then, we could almost clear out this entire backlog. I know that isn't realistic, but can we do at least half that? Two thirds, even? I think we can! Add in valuable sign-offs from non-committers, and our chances are that much better. To help in this endeavor, I am going to make two suggestions. First, I am going to recommend the judicious use of the "Incomplete" status. Some pullrequests sit around and rot because the provided code is a little funky, or the solution/feature is controversial, or the code simply doesn't seem to work. If anyone reviews a pullrequest, but doesn't commit (or sign off) on these sorts of grounds, please mark the bug as incomplete and leave a comment explaining why. While the window would still be open to address the concerns and get it committed before m1 arrives, any tickets marked "Incomplete" will be considered "done" for this round when assessing our goal completion rate. Second, and especially for committers who tend to be more conservative in the review process (you know who you are), I think we should temporarily and collectively lower the review bar to "pretty good". Try to consider the nature of the code change, such as "how much" and "what parts of the system", and make your level of testing in line with the character of the changes, rather than attempting perfection. This temporary attitude adjustment means two things: you will not be shamed for any bad commits done in the next week, and anyone running from master might want to put any pulls on hiatus for the next week or two until the dust settles. I think some level of "planned instability" is our best hope at keeping things on track, and is far better than the most likely alternative: unplanned instability (a.k.a. the mad rush). Important Dates: 5/28 (was 5/27) - (suggested) last day to target bugs/features for m1 6/4 (was 6/3) - goal date for having all m1 bugs/features committed to master As always, additional thoughts and concerns are welcome! Thanks, Dan -- ********************************************************************************* Daniel Wells, Library Programmer Analyst [email protected] Hekman Library at Calvin College 616.526.7133
