On 2013-12-06 12:19, Jay Dobies wrote:
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?
Not that I know of. Part of using an incubating project is that
incompatible changes can be made at any time. I'm well aware how
painful that can be if you're trying to consume such a project
downstream (I've been there), but that's the price for using a project
that hasn't released yet.
-Ben
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
