----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
Sent: Friday, May 31, 2013 12:03:09 PM
On 05/31/2013 06:56 PM, Einav Cohen wrote:
>>> ...
>>>
>>> [1] my main concern is that this batch of patches (dialog reorg) will
>>> make
>>> it into ovirt
>>> 3.3, but the second batch (which will contain the actual Instance Types
>>> fields) won't make
>>> it in time [see the ovirt 3.3 schedule in:
>>>
http://www.ovirt.org/OVirt_3.3_release-management -
>>> ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see
ovirt
>>> 3.3 being released
>>> with only the first patch batch merged into it. either both batches
>>> should
>>> be there, or
>>> both batches should not be there.
>>
>> There was a discussion about postponing it, but not much further it seems.
>> In any case It may not be necessarily wrong to have dialog reorg in 3.3
>> without insttypes as it will at least get people to get used to it and we
>> can gather feedback. It's not that it removes any functionality, on the
>> contrary, e.g. the type ahead feature even solves some of the bugs we
>> already have.
>
> indeed - it doesn't remove functionality, and I agree that it would be a
> good
> opportunity to get feedback about some things such as the type-ahead list
> box,
> however the top static header in particular with only the DC/Cluster +
> Quota
> in it may seem strange / annoying, as it would just seem like something
> that
> takes up "real estate" in the dialog in *all* side-tab without a real
good
> reason.
but the optimize for desktop/server already start to affect other panes?
quoting Tomas:
"""
the first patch we are talking about (
http://gerrit.ovirt.org/#/c/14635)
adds only Data Center, Cluster and Quota to the header.
There is a second patch (
http://gerrit.ovirt.org/#/c/15011/) which moves the OS type and
template to the header.
"""
so IIUC, the first patch batch [2] will include moving the following fields into the
static header:
- DataCenter/Cluster
- Quota
- OS type
- Template
@Tomas - I suggest that you will clarify:
A) which fields exactly are going to be included in the top static header of the New VM
dialog *in your current patch batch* [2], and:
B) which side-tabs in the New VM dialog will be affected by the fields in (A).
[there is a chance that the fields in (A) already affect a lot of the side-tabs, which
means
that it would actually make sense to introduce the top static section in the current patch
batch, even without the Instance Types / Images fields included in it, which is what (I
think)
Itamar is implying]
[2] the current patch batch, to my understanding, is:
http://gerrit.ovirt.org/#/c/14635/
http://gerrit.ovirt.org/#/c/14810/
http://gerrit.ovirt.org/#/c/14936/
http://gerrit.ovirt.org/#/c/15011/
http://gerrit.ovirt.org/#/c/15048/
http://gerrit.ovirt.org/#/c/15102/
http://gerrit.ovirt.org/#/c/15199/
>
> so there are pros and cons for introducing only the first patch batch to
> ovirt-3.3,
> I guess; Ideally, I would suggest to maybe re-organize the patches a bit
> differently,
> so that the top static header in particular wouldn't be part of this first
> patch batch,
> i.e., I would suggest introducing the top static header along with adding
> the Instance
> Types fields [which, to my understanding, is exactly what Daniel has
> originally suggested
> on the patch [1] in his gerrit comment(s) from May 28/29 (depends on the
> timezone) -
> only now I fully understand his concern (I think/hope)...].
>
> not sure how easy it is to do though - I know that *a lot* of time and
> effort were
> already invested in these patches as they are now, and I wouldn't want that
> the reviewing/
> merging process will be held off for much longer.
>
> To sum up: these are the options, as I see them:
>
> 1) keep the current patch batch as is and:
>
> a. merge it in time for ovirt-3.3, or:
>
> b. merge it post ovirt-3.3.
>
> - or -
>
> 2) go with what Daniel has suggested in his gerrit comment: reorganize the
> patches so that
> the top static header would be introduced only along with the instance
> types fields [that
> way, it won't matter what makes it into ovirt-3.3 - the first patch batch,
> or both (or none)].
>
> I am in favor of (1.b) or (2). However, weighing the cons of (1.a) against
> the pros of (1.a) /
> cons of (1.b) or against the effort that (2) will require, and taking into
> consideration the
> effort that was already invested, I am not strongly against (1.a) as well.
>
> [1]
http://gerrit.ovirt.org/#/c/14635/
>
>> ...
>
>