On Tue, Oct 15, 2019 at 07:32:41PM +0300, Laurent Pinchart wrote:
Well, this is largely what GitGitGadget does
(https://gitgitgadget.github.io), and we could go that route, sure. I'm
reluctant only because, quoth:
GitGitGadget itself is a GitHub App that is backed by an Azure
Function written in pure Javascript which in turn triggers an Azure
Pipeline written in Typescript (which is really easy to understand and
write for everybody who knows even just a little Javascript),
maintained at https://github.com/gitgitgadget/gitgitgadget.
I have zero familiarity with any of the above. That said, we do have a
bunch of CI engineers working at the LF, and I can probably avail myself
of their expertise if we decide to set this up.
I certainly wouldn't recommend a solution based on a proprietary
closed-source stack :-) But as we're talking about performing new
development for patchwork, I wanted to point out that we could also
consider a different technical approach that would involve new
development for a different open-source project. For instance, is the
above idea something that could be developed on top of gitolite ? Or
possibly even as a tiny standalone git server ?
I wouldn't do it on top of gitolite, because the administrative overhead
would be too large. It certainly can be done as a separate service --
after all, any relation between this tool and patchwork is pretty
tenuous.
That said, I'm leaning towards shelving this idea for the moment, at
least as an official service provided by kernel.org -- it is easier to
limit the scope at first and target maintainer tools and communication
frameworks. It seems that sr.ht folks are already making something like
this available, so we can just sit on our hands for a bit and see where
this takes us.
-K
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
