Open Stack

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