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. or collaborate with someone more knowledgeable > on the specific component to make the change in sync, or do the patch > yourself. > to make less code deprecated, the old api could wrap the new > functionality (call removeDisk in a loop, etc.). > it should still be flagged as something to clean up once the api calling > it is removed. > obviously, collaborating (or doing it thyself) on a sync'd change is > easiest, but not always possible. _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
