Re: [Engine-devel] static header only in VM dialog?

From: "Einav Cohen" <ecohen(a)redhat.com&gt; To: "Itamar Heim" <iheim(a)redhat.com&gt;, "Tomas Jelinek" <tjelinek(a)redhat.com&gt; Cc: "Michal Skrivanek" <michal.skrivanek(a)redhat.com&gt;, "Eldan Hildesheim" <info(a)eldanet.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt;, "Eldan Hildesheim" <ehildesh(a)redhat.com&gt;, "Daniel Erez" <derez(a)redhat.com&gt;, "Malini Rao" <mrao(a)redhat.com&gt; Sent: Friday, May 31, 2013 6:28:19 PM Subject: Re: [Engine-devel] static header only in VM dialog? > ----- Original Message ----- > From: "Itamar Heim" <iheim(a)redhat.com&gt; > 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/ > > > >> ... > > > > > >