Merge lp://qastaging/~justin-fathomdb/nova/strongly-typed-image-model into lp://qastaging/~hudson-openstack/nova/trunk

Our model to gather feedback on an idea is to discuss it at a design summit... I realize those only occur every 6 months so it's not applicable for things that _need_ to land quickly, but for all others, that's the way to go (faster consensus than MLs)

The second best model (for things that need to land quickly) is to use the ML... Adding one more review to the review queue to get feedback on a proof-of-concept sounds a bit counter-productive at that point in the cycle, and more people read the MLs than the merge proposal queue.

For this idea in particular, that sounds like a good discussion to have at a summit in Santa Clara, if you'll be there.

I don't think it's sufficiently revolutionary an idea to warrant discussion
on the mailing list or at the design summit! It's more an implementation
than an idea; it's a low-level code concern that should be run past the
people that have to work with the code, not the people that use the code
(ML) or the people who dream in UML (Summit) :-). Given it's for discussion
by nova-core, so this seems like a great tool - perhaps even better than a
nova-developers mailing list, because the code is right here.

I'd welcome your input on how to indicate that this shouldn't land. Perhaps
we should file a feature request with launchpad for a way to use launchpad
for this?

I will be at the design summit if I'm invited, BTW :-)

On Tue, Mar 8, 2011 at 3:32 PM, justinsb <email address hidden> wrote:
> I don't think it's sufficiently revolutionary an idea to warrant discussion
> on the mailing list or at the design summit!  It's more an implementation
> than an idea; it's a low-level code concern that should be run past the
> people that have to work with the code, not the people that use the code
> (ML) or the people who dream in UML (Summit) :-).  Given it's for discussion
> by nova-core, so this seems like a great tool - perhaps even better than a
> nova-developers mailing list, because the code is right here.

That's a completely ludicrous statement, Justin, sorry. Since when did
the ML only contain people who don't work with the code?

This type of thing is perfect for the ML. You could at least give a 2
paragraph summary of:

a) what is the base problem you want to solve
b) why your proposed solution is a good one

I know certain people just like to whip up prototypes, but the ML is a
greater audience and can generate ideas for you before prototyping.

-jay

META: I like the concept of having code & discussion in the same place. I'm also good with having code pre-blueprint or discussion, since we all understand code, probably more-so than English in a lot of cases. I just wish we could comment inline with the code :(. I agree this isn't a big enough idea to require summit discussion, unless we want to make it about preferring objects to hashes in general and talking about the places those are used and their ramifications (eg, serialization over the queue).

As far as this patch, I like the direction it is going. It probably needs a rebase and should take into account some of the changes that went in today: http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/revision/768.

I trust in the final version you'll remove the dead code that is hiding in comments (since KeyError shouldn't be raised anymore anyway).

I don't particularly like the PyLint hacks. I don't mind type-checking the incoming parameter so much as I mind returning after a raise. Is there no way to give pylint inference hints in comments?

Thanks for the meta - I wish we could comment directly on the code as well,
but it's still a lot closer than the alternatives.

Definitely this is not a completed work.. there's a lot of messiness in the
commented out code which I'm hoping to remove entirely! And it definitely
needs a rebase, or else I think vish will kill me if this somehow ends up
landing first!

I don't particularly like the PyLint hacks. I don't mind type-checking the
> incoming parameter so much as I mind returning after a raise. Is there no
> way to give pylint inference hints in comments?

I quite like type-checking the incoming parameter as I think it makes the
code more understandable, but I'm an old school static-typist at heart!

I agree that the hack is fugly, but I haven't yet found an alternative (and
I did look!)... I'm hoping somebody will chime in with "you just write
@returnType(Image), dummy!" or something like that :-)

It is possible to hide the hack in a shared "checked_cast(o, cls)" function,
so the monstrosity could only appear once, but hopefully we can get that
down to 0 somehow.

Though this patch is small, the underlying principles are pretty big change - dicts vs real objects.

If we approve this patch, now one small subset of code works in a completely different way than the rest of the codebase, and without a clear path forward, this is actually more harmful than helpful.

That said, I personally prefer to see real objects instead of dicts everywhere. Dicts are breeding grounds for bugs and we've seen a ton of bugs relating to dict formats.

But we can't approve this patch without looking at the bigger picture.

Devin: Sounds like you agree that Dicts are problematic, and agree with the object approach. This is only a proof-of-concept branch, but you're right - even if it is was rebased, we probably want to consider the whole codebase (though we'll still have to start somewhere!)

Thierry has suggested a Design Summit discussion on this issue; I think that maybe we could have one for the 'big picture' of removing Dicts and in general trying to get more help from PyLint and Python. "Engineering in quality". I feel we have a lot of rules about code formatting, but comparatively few about writing quality code or defensive code.

Thierry: How can I propose this as a topic for the design summit?

If I can do that, I think I'll close out this merge request (but link to it), as I feel that's a reasonable path forward. It doesn't seem like anyone is standing up in support of Dicts :-)

Despite the fact that I disapproved of actually merging this in, I think it's great and something I have been campaigning for myself actually.

I think it would be a great design summit discussion. I don't have his info immediately available, but you should contact Stephen Spector about topics for the design summit.

How to add a topic for the design summit:

* Create a blueprint in Launchpad for the corresponding project
* Under "Definition status", select "Discussion" if you need a brainstorm session (~45-55min)
* Under "Definition status", select "Review" if you need a rubberstamp session (~10-15min)
* Under "Propose for sprint", select "Openstack Design Summit - Diablo"

That's all !

How to choose between Rubberstamp and Brainstorm ? It depends on the state of your idea. If it's fully specified (and described in a document linked to the blueprint) and just needs to be publicly discussed so that people can voice their remarks about it, select "Review" (Rubberstamp). If you're still brainstorming the design and would like to get the collective mind of fellow developers to help in choosing the right design, select "Discussion" (Brainstorm).

I'll post this procedure on the wiki / ML soon.