On Tue, Feb 8, 2011 at 5:43 AM, Thierry Carrez <[email protected]> wrote: > With Bexar behind us I'd like to have your feedback on how the recent > cycle went from your perspective, so that we can build on what worked > well and fix or improve what went bad: > > * Release schedule > * Use/abuse of freezes and exceptions > * Technical focus of the release > * Tracking (Launchpad blueprints) and reporting (releasestatus page) > * Too much/too little QA compared to the size of the merge window > * RC bugs tracking > * Release week
Hi Thierry, Here's my opinion on what went well and what didn't go so well. 1) Screwed up importing translation .po files and automating the compilation of message catalogs into the tarballs This was entirely my fault. I forgot to write the script that compiles the .po files into the binary message catalogs and merge that back into trunk. Though I had this as a work item on the i18n blueprint, I marked the blueprint Implemented before that was actually completed, so I totally forgot about it by release time. Lesson learned: Break blueprints with significant work items out into multiple blueprints or bug reports to make sure things don't get "left behind" 2) The live-migrations patch Clearly, we collectively dropped the ball on this. Here are some things that I feel could have been done better: Some things to note: * More reviewers needed on critical, large patches like live-migrations, and this review needs to happen *early and iteratively*. * Less confrontational discourse and blaming of individual developers or reviewers. We need to remember that all contributors are in this together, and that we are all working together towards a unified direction. Have a problem with a review? Address the reviewer and ask for a specific set of changes. Do it nicely. * The contributor(s) of the patch and the release manager should have a responsibility to nag and bug core reviewers for detailed reviews. If you have a patch that you really want to get in, and reviewers are not showing up to do reviews, *do not hesitate* to mail the mailing list multiple times for reviews. Don't be afraid to nag if there is no immediate response. 3) Little to no communication about large patches/changes We need more, clearer communication and discussion about large patches that are proposed. As an example (not the only example, but a good example from this past release series), the Easy API patch was proposed late in the game and generated a lot of confusion within various groups as to what the patch was and why it was useful. Some things to work at in the next release: * For anything that may be controversial and/or have far-reaching effects, use the mailing list for discussions to flesh out what it is the blueprint is about * Have a blueprint for what you work on if its a large patch. Just proposing some large patch without a blueprint or any discussion creates a situation (usually at just the wrong time in the release and review process) where reviewers get distracted from reviewing patches that have blueprints and discussion associated with them 4) Feature overload and need for better testing IMHO, the Bexar release had too many new feature blueprints targeted at it. Unfortunately, Cactus seems to be following the same route in order to achieve feature parity on an API level. We need more focus on testing for the following: * Deployment and packaging tests -- i.e. do we install easily and correctly on all platforms we claim to support? * Configuration tests -- i.e. if I stray from the default configuration options, does my install blow up? * Integration tests -- i.e. if I set up Swift, Nova, and Glance, do they all work together properly? Are the limitations of inter-operability *documented*? * Multi-node tests -- i.e. if I install Nova on multiple nodes, do things work as expected? I think it's obvious from the bug reports that came flooding in during the last few weeks of Bexar that the above testing needs are sorely needed. 5) Documentation missing There is still a ton of hole in the documentation for Nova. Professional software has professional documentation. While Anne has made significant (and much appreciated) gains in the documentation department, she needs the help of developers to fill in the myriad holes in the documentation. Proposal: No feature patches should be accepted without the patch containing documentation on the feature. Period. Just my 2.5 cents. -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
