UbuntuDevelopment/CodeReviews

[Onno Benschop]

On 23/10/08 22:22, Bryce Harrington wrote:
> Basically, the idea would be to have a build farm routinely scan
> launchpad for patches and attempt to apply / build / test them.  It
> would then mark patches PASS/FAIL appropriately for each build or test
> run done.
>
>
> So, like apport-retracer, but with a test/build farm as its backend.
>
> In addition to giving mechanical feedback about patches (applies,
> builds, passes smoke tests, etc.) as byproducts it could provide .debs
> for testing.  In fact, I would suspect this latter feature could
> stimulate a lot of LP usage by itself.
>   

I wonder if this level of automation comes with some hidden land-mines.

How would you protect against rogue code in this scenario - both from a
licensing and a malicious perspective?

If you are going to mark a patch as PASS/FAIL, it's only a short step
(potentially a mouse-click) from there into acceptance.

If you go on to build a .deb, you're even closer.

I'm not saying the idea is bad, in fact I really like the idea, it would
help me as a contributor test my patches before I need to knock on
someone's door to get them to have a look at it.

There are resource implications as well. I think your idea might be used
differently than you expect. I find myself thinking about patches I've
made in the past and how I felt limited in my contributions by the fact
that I refuse to run an unstable OS (as-in, not yet released, as opposed
to crashing all the time :) on my income generating workstation. This
idea would allow me to make a patch, then upload it to LP and have it
come up with all the bits that it needs to build the package and then
tell me that I made an error.

-- 
Onno Benschop

Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA)
--
()/)/)()        ..ASCII for Onno..
|>>?            ..EBCDIC for Onno..
--- -. -. ---   ..Morse for Onno..

ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219 8888   -   onno at itmaze.com.au