hi Krisztian, Anyone who's developing in the project can see that the Buildbot setup is working well (at least for Linux builds) and giving much more timely feedback, which has been very helpful.
I'm concerned about the "ursabot" approach for a few reasons: * If we are to centralize our tooling for Arrow CI builds, why can we not have the build tool itself under Arrow governance? * The current "ursabot" tool has GPL dependencies. Can these be factored out into plugins so that the tool itself is ASF-compatible? * This is a bit nitpicky but the name "ursabot" bears the name mark of an organization that funds developers in this project. I'm concerned about this, as I would about a tool named "clouderabot", "dremiobot", "databricksbot", "googlebot", "ibmbot" or anything like that. It's different from using a tool developed by an unaffiliated third party In any case, I think putting the build configurations for the current Ursa Labs-managed build cluster in the Apache Arrow repository is a good idea, but there are likely a number of issues that we need to address to be able to contemplate having a hard dependency between the CI that we depend on to merge patches and this tool. - Wes On Thu, Sep 5, 2019 at 8:17 AM Antoine Pitrou <anto...@python.org> wrote: > > > Le 05/09/2019 à 15:04, Krisztián Szűcs a écrit : > >> > >> If going with buildbot, this means that the various build steps need to > >> be generic like in Travis-CI (e.g. "install", "setup", "before-test", > >> "test", "after-test"...) and their contents expressed outside of the > >> buildmaster configuration per se. > >> > > This is partially resolved with the Builder abstraction, see an example > > here [1]. We just need to add and reload these Builder configurations > > dynamically on certain events, like when someone changes a builder > > from a PR. > > This is inside the buildmaster process, right? I don't understand how > you plan to change those dynamically without affecting all concurrent > builds. > > Regards > > Antoine.
