----- Original Message ----- From: "Itamar Heim" <iheim@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/
...