launchpad-dev team mailing list archive

[Celso Providelo <celso.providelo@xxxxxxxxxxxxx>]

On Mon, Aug 10, 2009 at 3:16 PM, James Westby<james.westby@xxxxxxxxxxxxx> 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.

Cool, we better reserve some time to make private branches fit in our
roadmap, but it's good to know that launching the service for
public-only is an option.

Thanks, James.

Resurrecting an old question: do you know why building remote branches
is not functional in jaunty ? `bzr bd -r REV BRANCH_URL`

Also, how can we cope with the feature-set variation of bzr-builddeb
across the supported suites ? Should we:

1. Always build branches on the development chroot
2. Use the chroot for the target suite + officially backported bzr-builddeb
3. Use the chroot for the target suite + an PPA overlay with the
semi-official bzr-builddeb backports


-- 
Celso Providelo <celso.providelo@xxxxxxxxxxxxx>
IRC: cprov,  Jabber: cprov@xxxxxxxxxx, Skype: cprovidelo
1024D/681B6469 C858 2652 1A6E F6A6 037B  B3F7 9FF2 583E 681B 6469