launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #01770
Re: Immediate plan for Build Farm generic jobs
Michael Nelson wrote:
>
>
> On Mon, Nov 23, 2009 at 8:57 AM, Michael Nelson
> <michael.nelson@xxxxxxxxxxxxx <mailto:michael.nelson@xxxxxxxxxxxxx>> wrote:
>
>
>
> On Wed, Nov 18, 2009 at 7:15 AM, Michael Hudson
> <michael.hudson@xxxxxxxxxxxxx <mailto:michael.hudson@xxxxxxxxxxxxx>>
> wrote:
>
>
> Julian Edwards wrote:
> > There is one nightmare part to this - the implementation of
> > IBuilder.findBuildCandidate(). This is currently a very ugly
> query that
> > decides which job to dispatch next, based on a few criteria
> about the jobs. I
> > expect it to get to troll-like ugliness by the time we finish
> and I'm not sure
> > how it will work yet, it depends on how Michael re-factors
> IBuilder and sets
> > up an interface that other builders must implement.
>
> Wow, that's a beauty alright.
>
>
> Hmm... as far as I understand it, we aren't going to have
> generalised builders that can do both binary-package building and
> branch->source package building initially right? Rather, we'll have
> different types of builders. So although we'll want to keep the
> scoring consistent for both so that when we *do* have such
> infrastructure they'll be queued fairly, currently each builder type
> will be able to implement its own findBuildCandidate() and only be
> looking for builds of the required type... in which case, the
> short-term solution for findBuildCandidate() should be pretty
> straight forward?
>
>
> Erm - my mistake. We won't yet have generalised builders that can accept
> jobs for different archs, but any builder should be able to do branch
> jobs (ie. non soyuz-build jobs).
I hope that's the case. I guess it means the other job types need to be
script-based, which I think they are at least for the recipe stuff.
Translations guys, what about the translations import jobs?
Follow ups
References