launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Tuesday 06 October 2009 23:28:21 James Westby wrote:
> Hi Julian,
> 
> Thanks for writing this.

No worries.  It's basically the top priority for Soyuz now and we need to get 
the ball rolling.

> The "or equivalent" here may need a little bit of discussion. I think I
>  know what that would look like, but it needs to meet LP and IS'
>  requirements.

Indeed, I was deliberately vague since I don't know much about how this works.  
I am sure you can enlighten me :)

> In my head it is bzr-builddeb without the bits that arbitrarily download
> things from the net, and the "hooks" that run extra code. The former
>  because that's the rule for PPAs, and the latter because that can require
>  extra dependencies that we have no way of specifying and so installing.
>  The problem I see with this is that we will get lots of users confused
>  because it builds locally but not on LP.

Right, it should fail as early as possible, or even prevent the build request 
if we already know it won't work.  Waiting for a network time-out is not an 
option on a busy build farm.

> This is certainly your domain, but I'm interested in what the
>  "identification and trust mechanism" would look like. There is something

I've not thought about it in any great detail yet (I am saving that for a 
design sprint) but since everything is inside Launchpad we can probably get 
away with something as simple as using a column on a database table that tells 
us who requested the build.

>  similar for binary uploaders from the buildds I guess? How would this look
>  different? Is it a requirement for doing things like recording the
>  uploaded in the source package publishing record?

Binary uploads are unsigned and we don't care about those, because we know 
they came from the build farm.

One of the reasons we do need to care for source uploads is that there's a 
whole pile of code out there that relies on knowing who uploaded the source, 
such as determining where to send emails, assigning karma, etc.

> >> I've made no mention of any UI beyond the first point, as I'm not sure
> >> we need anything else. M-BM- We can enhance the existing /builders page
> >> to give more on waiting BFBs. M-BM- Can you think of any other UI
> >> changes we'd
> >
> > I think that we may want to preserve the information of where the
> > package got built from, so there's a link to the source branch on the
> > UI.
> 
> Yes please, preferably also recording the revision that was built.

Good point!  We can add something to the existing source package pages.

J