On 01/18/2012 09:38 AM, Livnat Peer wrote:
On 18/01/12 00:46, Itamar Heim wrote:
On 01/17/2012 06:35 PM, Livnat Peer wrote:
...
We can't remove cloneTemplate until it is removed from the UI or else we
will break functionality. For now we are just going to ensure that it
works as it always has until the UI is ready to remove it.
If by ensure you mean you are going to do adjustments for the
cloneTemplate code to work then it is not needed.
You can either send a patch to disable/remove this button from the UI
or synchronize your patch with a patch from the UI that removes this
button.
I don't like the approach of leaving the code because many times we end
up with a code that is not used and not maintained.
I don't think a patch which would make existing functionality disabled
is the way to go.
I expect a lot of times a new functionality will be added, and the old
one should be flagged deprecated with a comment as to why (or open a BZ
to self to clean it up),
I don't expect that we'll remove functionality a lot of times, this was
a gap in the API modeling that enabled us doing that.
If i understand correctly then you expect to add the clone disk
functionality to the UI before removing the clone template button.
Let's assume this requires a rewrite of the command to work with the new
DB schema, this would be a throw away code, should it be done? I think not.
We have upstream releases which should be stable - preferably with no
partial functionality, other than that there is a development going on
in upstream and from time to time some of the functionality won't be
fully ready, it does not mean the application is broken but a disabled
button in the UI or something similar can be a valid state IMO.
I think the assumption is someone should always be able to take upstream
HEAD and build/base a version on it, other than the formal versions.
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
