On Fri, Sep 6, 2019 at 12:23 AM Wes McKinney <wesmck...@gmail.com> wrote:
> 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. > How should we move forward with the donation? Should we have a separate thread for voting? Do we need any special steps for the IP clearance? > > - 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. >
