openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2011/7/27 Trey Morris <trey.morris@xxxxxxxxxxxxx>:
> I'm fairly certain that in this particular case, without support from the
> hypervisor and api lieutenants, and a testing guru or two, I would still be
> trying to fit all the pieces together.

On any reasonably large software project, sometimes making changes to
the code isn't just about making changes to the code. Sometimes it
involves pestering people to help you out if there are things you
can't work out yourself.

> Merging with broken pieces in this case was necessary.

I absolutely, nonequivocally disagree.

> Some more thoughts to fuel discussion...
> 2) shims:
> Sandy would say we could use shims here, wait for the other parts to be
> merged, then remove the shims in such a way that nothing is ever broken. I
> think a procedure like this works in the vast majority of cases, and makes
> for smaller merges with trunk. Certainly we don't want shims in place any
> more than we want skipped tests, so how do we get the pieces updated? Who is
> going to do the updating?

Maybe I'm not completely clear on what you mean by "shims". Do you
mean wrappers for backwards compatibility?

> 3) skipped tests:
> Very visible. Everyone sees them. But very bad habits can be formed around
> using them.

a) Not everyone sees them. I rarely sit around and stare at the test
suite run. If it fails, yes, I go back and look, but if it all passes,
I don't care much about its output. This is, in fact, how I discovered
this: I made a change to the test suite that I *knew* should make it
fail, but it didn't. *Then* I went and looked and saw all of these.

b) I never for a second assumed that a skipped test meant that it was
my problem to fix it. If someone disables a test, I assume they're
working around the clock(!) to fix the problem.

> 4) dropped support:
> We've decided to add feature X to Nova. Developer A determines adding X
> requires nontrivial changes to hypervisors Q W E and R (and yes, soren,
> their tests). Developer A, being familiar with Q, updates Q (and tests) to
> work with Nova+X; however, W E and R are still broken. If requests for
> option 1 above fail and cooperation doesn't seem to happen and things drag
> out, we should remove the shims, merge, and drop support for W E and R from
> Nova until updated code (with tests) for W E and R is proposed for merging
> into trunk.

I'm perfectly fine with this. If no-one wants to maintain a particular
hypervisor, it gets dropped. This is perfectly reasonable.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/