arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Krisztián Szűcs <szucs.kriszt...@gmail.com>
Subject Re: [PROPOSAL] Consolidate Arrow's CI configuration
Date Fri, 06 Sep 2019 08:21:01 GMT
On Fri, Sep 6, 2019 at 12:23 AM Wes McKinney <wesmckinn@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 <antoine@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message