> On 7/28/15 3:19 AM, Finucane, Stephen wrote:
> >>>> For what it's worth, I also think that something like Gerrit would be
> >>>> useful given the number of platforms that OVS is running on. Right
> >>>> now, it's seems like we're doing the human-powered version, which is
> >>>> Guru, Daniele, or Ben complain when something breaks Windows, DPDK,
> >>>> 32-bit respectively. It also effectively provides the features of
> >>>> Patchwork in a way that is more maintainable.
> >>>>
> >>>> I agree that the Gerrit UI sucks (I haven't tried the OpenStack
> >>>> interface) and maybe there are alternatives, like Github's set of
> >>>> tools. But I think the status quo that we have isn't all that great
> >>>> either and I also would like to avoid having a collection of
> >>>> independent tools that fall apart over time.
> >>>
> >>> I'm happy to encourage people to submit changes via Github, as an
> >>> experiment.
> >>
> >> I think this is a reasonable place to start, especially since we
> >> already have the infrastructure set up. I think the main thing to try
> >> out is whether we are OK with this type of workflow for reviewing
> >> patches as opposed to the mailing list, so at some level it doesn't
> >> matter where we start.
> >>
> >> I don't think that Travis CI is good enough to handle all of the
> >> pre-checkin tests that we would like to do (kernel, Windows,
> >> performance, etc.) but it looks like there are other tools that have
> >> integration with Github that minimally should be the same as what
> >> Gerrit can do.
> >
> > I'm obliged to point out the work that's ongoing to get some level of
> automated testing going in patchwork (for use with DPDK):
> >
> > https://lists.ozlabs.org/pipermail/patchwork/2015-July/001363.html
> Stephen, thanks for bringing this up.
> >
> > However, I still think Gerrit is the more mature, feature-filled solution
> if mailing list-based development isn't an absolute necessity. OpenStack
> really have the Gerrit process nailed.
> >
> My question would be how to handle multi-architecture support required
> for testing kernel module. It seems like a mechanism that we are working
> on for DPDK would work well because it is decentralized. The testing for
> each arch and target environment, Linux revision etc. is "farmed out" to
> jenkins or some other CI tool that only have to report the result via
> email which is in turn is summarized by patchwork.
See the 'PS:' below. Third party CIs, maintained by someone with said
architecture, could be used for this. Have a look at the "Jenkins check" table
for this review in OpenStack Gerrit:
https://review.openstack.org/#/c/202655/
You'll see there's at least the third party CIs commenting on the change:
* IBM PowerKVM CI
* Intel PCI CI check
* Microsoft Hyper-V CI check
* Virtuozzo Storage CI check
These CIs mostly check different hypervisor support, but architecture support
for OVS would be virtually the same thing. My own team here in Intel, for
example, have a CI job validating NUMA topology features of OpenStack Nova. We
don't report these results yet, but we could!
Stephen
> > Someone really needs to fix that web UI though...
> >
> > Stephen
> >
> > PS: Third party CI support (a lá OpenStack) would be an incredibly useful
> feature to offload some level of testing (like performance testing of the
> DPDK element of OVS). It's probably not an option with GerritHub (I haven't
> checked), but if you're deciding to go all in on Gerrit or not then this is
> one for the PROS column.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
