On 2013-12-06 09:37, Tzu-Mainn Chen wrote:
Hey all,
We're starting to work on the UI for tuskar based on Jarda's
wireframes, and as we're doing so, we're realizing that
we're not quite sure what development methodology is appropriate.
Some questions:
a) Because we're essentially doing a tear-down and re-build of the
whole architecture (a lot of the concepts in tuskar
will simply disappear), it's difficult to do small incremental patches
that support existing functionality. Is it okay
to have patches that break functionality? Are there good alternatives?
This is an incubating project, so there are no api stability promises.
If a patch breaks some functionality that we've decided to not support
going forward I don't see a problem with it. That said, if a patch
breaks some functionality that we _do_ plan to keep, I'd prefer to see
it done as a series of dependent commits that end with the feature in a
working state again, even if some of the intermediate commits are not
fully functional. Hopefully that will both keep the commit sizes down
and provide a definite path back to functionality.
b) In the past, we allowed parallel development of the UI and API by
having well-documented expectations of what the API
would provide. We would then mock those calls in the UI, replacing
them with real API calls as they became available. Is
this acceptable?
This sounds reasonable to me.
-Ben
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
