launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

James Westby wrote:
> 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.

I think this is a very sane approach; I'd expect the difficulties with
private branches to be basically orthogonal to the difficulties just
getting the basic setup going, so let's not try to do everything at once.

Cheers,
mwh