On Tue, 2018-09-04 at 16:11 +0200, Erik Skultety wrote:
On Tue, Sep 04, 2018 at 01:01:34PM +0200, Andrea Bolognani wrote:
> Up until now, we've been considering MinGW builds as
> part of the respective project, at least when it
> comes to grouping them. This, however, does not quite
> work for a number of reasons:
>
> * MinGW builds have their own workspace, separate
> from the native one. It goes further than that:
> even the 32-bit and 64-bit builds use a workspace
> each, which goes to show that grouping all three
> together is inaccurate;
Well, I'd say that if someone cares enough about libvirt mingw builds, then they
probably care about both ABI versions in which case they'd most probably prefer
not having to specify for which x86 arch build they're interested in, therefore
having both of these in the same project playbook, e.g. libvirt+mingw.
Fair enough, but that's still supported quite naturally by using
'libvirt+mingw*', whereas the opposite wouldn't be true if we
grouped them together; moreover, grouping them together ignores
the fact, mentioned above, that they already use separate
workspaces, and would additionally mean we'd have to keep the
concept of 'variant' around instead of getting rid of it and
wouldn't be able to have the separation cleanly mirrored in
every aspect from project names (in the vars/projects/ and
host_vars/*/ sense) to Jenkins job names.
All in all, it looks to me like a partial split has several
disadvantages over a complete split and zero advantages, so
I'd rather not go down that road.
--
Andrea Bolognani / Red Hat / Virtualization