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.