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

[Tomas Jelinek]

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
> <engine-devel at ovirt.org>, "Eldan Hildesheim" <ehildesh at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Malini Rao"
> <mrao at redhat.com>
> 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 at 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:
- Data Center
- Cluster
- Quota
- Template (because according to the mockup the Image field will contain both Template and Image, so until we have images, just templates are there)
- Vm Type (e.g. if server or desktop)
- OS type
(well, basically according to mockup, just without the instance type)

> 
> B) which side-tabs in the New VM dialog will be affected by the fields in
> (A).
More or less all with some exceptions - especially thanx to the template field. And this will not change at all after introducing instance types/templates because
template = instance type + image. So the question is not really if we want to wait until the instance types and images will affect enough side tabs (because that
will not change at all) but if we want to have a top header panel or not. I personally start to think that it is more or less a question of taste. 
One may argue that it makes the dialogs more understandable (by having context all the time) and other that it makes them more un-understandable by flood of information in context you don't need.
I guess either way has some advantages and disadvantages and there is no strict good/wrong solution. 

> 
> [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/
> > >
> > >> ...
> > >
> > >
> > 
> > 
>