Open Stack

>> 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.

Is there any sort of policy or convention of sending out a warning 
before that sort of thing is merged in so that people don't accidentally 
blindly pull master and break something they were using?

>> b) In the past, we allowed parallel development of the UI and API by
>> having well-documented expectations of what the API

Are these expectations documented yet? I'm new to the project and still 
finding my way around. I've seen the wireframes and am going through 
Chen's icehouse requirements, but I haven't stumbled on too much talk 
about the APIs specifically (not suggesting they don't exist, more 
likely that I haven't found them yet).

>> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>