Re: [libvirt] [jenkins-ci PATCH v5 4/5] mappings: extend mapping to allow per-arch entries

On Tue, 2019-02-26 at 11:00 +0000, Daniel P. Berrangé wrote: I feel like the order entries are processed with this implementation can be quite counter-intuitive. The root problem of course is that up until this point we have had a single axis to work on, and we're now introducing a second one which is independent of the existing one but which we still have to fit along with it into the same flat hierarchy somehow... Consider an example such as foo: Fedora: oldfoo Fedora-s390x: FedoraRawhide: foo The general intuition up until now has been that appending something to a label would make it more specific, and only one item on each level would possibly match, but now both Fedora-s390x and FedoraRawhide appear to be on the same level and *both* could apply to an s390x Fedora Rawhide machine, making it less clear which one would take precedence. I suggest that the example above would be rewritten as foo: Fedora: oldfoo FedoraRawhide: foo s390x-Fedora: where two changes happened: first of all, the lines have been shuffled around to match the order they would actually be processed, which is something that we could have done with the above as well, but more importantly the architecture name is now *prepended* to the existing labels to clearly signal that it's part of a completely separate hierarchy. The ambiguity is now gone entirely, and which entry has precedence is easier to see at a glance. Implementing this alternative proposal requires only very minor tweaks to the code you posted. [...] This should be a @staticmethod in the Utils class. I'd also rename it to get_native_arch(). [...] Updating the documentation as you implement new features is good, but these last two hunks should go in a separate commit. -- Andrea Bolognani / Red Hat / Virtualization