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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
