Dan Smith <d...@danplanet.com> writes: >> You may have noticed that this has merged, along with a further change >> that shows the latest results in a table format. (You may need to >> force-reload in your browser to see the change.) > > Friggin. Awesome. > >> Thanks again to Radoslav Gerganov for writing the original change. > > Thanks to all involved, as this is a major improvement for everyone! > > One thing that we discussed at the nova meetup was having a space for > each CI we *expect* to vote. I haven't looked at the implementation > here, but I assume it just parses the comments to generate the table. > How hard would it be to make the table show all the CI systems we expect > so that it's very obvious that one has gone MIA (as they often do) > before we merge a patch? I think we struggle right now with merging > things that a CI system would have NAKed, but only because we didn't > notice that it hadn't voted.
I think my preferred method of doing this would be to drive all third-party CI systems from OpenStack's Zuul. We are not far from being able to do that technically, though it's not clear to me that there is the will for third party CI systems to do that. However, if we really are expecting them to report back and are willing to hold up merging a change because of it, then we really should consider that. As we look into using a Gerrit plugin for test results, we could see about adding that as a feature. Something that we could technically do immediately would be to add third-party CI systems as reviewers to changes when they are uploaded. Then they would show up in the list of reviewers at the top of the change. This would require maintaining a list of which systems were expected to vote on which repositories. Rather than keeping that in git, we could use group membership for it (and implement something we have talked about off-and-on, which is using Gerrit group membership to grant voting privileges to each individual repository). That would also allow projects to self-manage both who is permitted to vote on their repos and who is expected to vote. -Jim _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev