Numan Siddique <[email protected]> writes: > On Fri, Nov 7, 2025 at 8:32 AM Aaron Conole via discuss > <[email protected]> wrote: >> >> Ales Musil via discuss <[email protected]> writes: >> >> > The initial discussion was held during the OVN technical community >> > meeting - November 3rd >> > [0]. The recent patchwork slowness that lasted for a couple of >> > months sparked a discussion >> > if it's reasonable to switch to a different patchwork instance or >> > platform completely. The >> > three options listed during the discussion were following: >> > >> > 1) Keep using the current system. >> > >> > 2) Switch to Github pull request based approach. That would mean >> > getting off the mailing >> > list completely. This has some advantages in regards to CI as we >> > wouldn't require to pull the >> > patches from ML and submit them into a separate repository to do >> > the testing. Another >> > positive thing might be attracting more contributors. However, >> > there are also downsides >> > PRs usually means series of commits being submitted together, that >> > might be hard to >> > review. The conversations in PRs are hard to follow in something bigger. >> > >> > 3) Use a different patchwork instance. One of the suggested >> > solutions might be to move >> > not only the patchwork instance, but also ML into Linux >> > Foundation. This should bring more >> > stability and the overall process would change from the outside >> > perspective, the possible >> > downside is that this process would be slow spanning over weeks, >> > maybe even months. >> > > > Given that patchwork is very slow again, maybe we should consider > moving forward with one of the options listed here. > My first preference would be option 3, followed by option 2.
Agreed - I prefer option 3 as well. It wouldn't take much to convert the ci infrastructure we're already using. I also see the slowdown on the ozlabs server. > Numan > > >> > 4) Use a Gerrit instance, during the meeting there wasn't a huge >> > discussion about gerrit and >> > given our choices it might actually be more of an extra unless >> > someone has a really good >> > reason why we would choose that. >> >> Gerrit brings in a host of problems, imo. Their workflow (especially >> when doing some change reviews) is extremely "opinionated" and I've >> found it to be very inflexible when I've used it in the past. >> >> I can think of more reasons *not* to choose Gerrit than to choose it >> (for example, the way it requires rebasing after changes). >> >> > The list is not exhaustive, any other suggestions are very much >> > welcome, plus the opinion >> > why certain options might be or not be a good idea. I would also >> > like to emphasize that this >> > is an open ended question. This thread should serve as a >> > discussion continuation. Please let >> > us know what you think. >> > >> > [0] https://mail.openvswitch.org/pipermail/ovs-dev/2025-October/426687.html >> > >> > Best regards, >> > Ales >> > >> > _______________________________________________ >> > discuss mailing list >> > [email protected] >> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >> _______________________________________________ >> discuss mailing list >> [email protected] >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
