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

[Daniel Erez]

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "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>, "Itamar Heim"
> <iheim at redhat.com>
> Sent: Friday, May 31, 2013 6:56:33 PM
> Subject: Re: [Engine-devel] static header only in VM dialog?
> 
> > > ...
> > > 
> > > [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.
> 
> 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)...].

Exactly, I prefer that the static header will be introduced along with the new dialog
I.e. squashed with the final dialog patch (with instance types fields).
I understand that the static header might make sense for the final dialog
(though I still don't like the idea that it's relevant only for some side-tabs).
Added my remarks to the patch: http://gerrit.ovirt.org/#/c/14635/

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