launchpad-dev team mailing list archive

[James Westby <james.westby@xxxxxxxxxxxxx>]

Celso Providelo wrote:
> On Mon, Aug 10, 2009 at 1:36 PM, Julian
> Edwards<julian.edwards@xxxxxxxxxxxxx> wrote:
>> Jono or James, how long does "bzr builddeb" take roughly?  Is it roughly
>> constant across packages or is there a notable difference?  My concern is that
>> we'll need more builders but if the job is quick enough we might not notice
>> them running.

It's a variable amount of time, but much shorter than the job the
PPA builders currently do. Most packages will be <~30s, but outliers
could take 10 minutes or more. That won't be too much of a load, but if
there is too much overhead in the dispatching then the increase in jobs
could require a lot more builders.

> That's where the magic of sharing the existing builders come, if it
> gets overloaded with branchjobs we can simple add more machines to the
> game when we notice they are needed. Considering that building source
> packages is essentially lighter than building binaries, I don't think
> they will cause a load that we cannot manage, even if there is some
> variation according the branch/source size.

+1

> Building branches will also generate more load on the lp smartserver
> ... which also brings the authentication topic to mind. Are we going
> to build private branches ? Similarly to what we do for building P3A
> sources we should restrict the access given to builders when dealing
> with private branches, since `debian/rules` contains arbitrary code.

As a first cut only building public branches would be a useful start.
However, I spoke with the OEM team at the sprint, and they seemed keen
to make use of this, so they would want builds of private branches.
There are also other teams in the company that would presumably want
to do this (desktop-experience?), so I imaging there would be
considerable pressure to support private branches.

Public-only as a start would be ok with me, as long as there was a
commitment to add support for private branches soon after.

Thanks,

James