openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Tue, Feb 8, 2011 at 5:43 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx> 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