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.