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