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

[Einav Cohen]

> > ...
> > 
> > [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)...].

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/

> ...