launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Tuesday 13 October 2009 04:29:53 Tim Penhey wrote:
> I agree with Jono that we should have some archive picker, but I'm not
>  against having a reduced functionality initial widget, as long as we are
>  careful not to exclude the future when making the initial widget.  I have
>  found in the past that it is often easier just to do the whole thing at
>  the start rather than adding limiting code early on.
> 
> I think we should have a separate discussion around what an archive picker
> might look like, and how various restrictions would play out.  For example,
>  if I have a package branch of lucid bzr, then how would we limit the
>  archives that it could be built into?

I don't think we should have an archive picker.  We should have a separate PPA 
picker and a distribution picker.

Users don't think in terms of archives, they think in terms of PPAs and 
distros.  In particular, a distro can have multiple archives and the rules for 
which archive a package ends up in are tightly controlled during the upload 
processing.

Also, once we have PPAs worked out, adding distro builds will be very easy so 
don't sweat over this one.

> That is probably the easiest bit.  The job creation.  The more interesting
>  bit also relates to something else Jono mentioned, and that is how to
>  report the status of a long running job.  Ideally on the branch page we'd
>  show the progress (or lack of progress) of any build job for the branch. 
>  Having a nice (standard) way to show pending or running jobs would also be
>  good for things like the branch upgrade job.

I think the branch page is the wrong place to report this, unless you want to 
see all the places it could be building?

I would expect to see build progress on the target's context page, e.g. a PPA 
or a Distribution Source Package page.

> >   * It's also possible that the branch build will fail so an email should
> >  be sent in that case.
> 
> Aaron has done some work on the job infrastructure recently to make it easy
>  to send emails for failures.  Hooking into that should be quite easy.

Aaron, fancing coming to UDS to talk about this?

> We will want to plan for some linking ability between a branch and an
>  archive to allow the build jobs to be created whenever the branch is
>  pushed to.

Yes, good point.  Some sort of "auto-build" linking table.  This will need UI 
work to set up auto-build targets, but I don't think it's part of the initial 
implementation to get builds going, it's more to do with the Crack of the Day 
stuff.

> James mentioned that there could well be confusion with some developers
>  where their package builds locally but not in the LP build farm.  I'd
>  suggest that we'd want to provide some flags to the build deb plug-in so
>  it could simulate the LP build environment with its non-downloading and
>  hookless bits.  This would then allow the devs to simulate the LP build
>  environment locally at least.

This is no different to the situation we have now with building source 
packages, and in fact we often have people complaining that the PPA builders 
are "broken" :)  They usually missed a build dependency that is already on 
their local system.  As long as they have access to the build log (they will) 
then it should be easy enough to figure out any problems.

I yet don't know enough about builddeb though to say what else we could do to 
make this better.

> One thing I am not clear on yet is whether the package branch contains
>  enough information itself to just be built.  If yes, then great, a simple
>  job should be all we need form the code point of view.  If more
>  information is needed, we'd need to work out how to capture that
>  information and also how it would work from the push to build point of
>  view.

I'm pretty sure it's self-contained.  James?

> You are right, most of this work does land on the soyuz side of the fence.

I see it as a good opportunity for you to learn more about Soyuz ;)

FYI we already have a blueprint for our buildd generalisation from a sprint 
held in the summer of 2008.  It's a good read: 
https://blueprints.edge.launchpad.net/soyuz/+spec/buildd-generalisation
(I moved the main spec from the old private wiki to the new dev wiki)

Cheers
J