UbuntuDevelopment/CodeReviews

[Jordan Mantha]

On Thu, Oct 23, 2008 at 07:22:41AM -0700, Bryce Harrington wrote:
> On Thu, Oct 23, 2008 at 12:12:18PM +0100, James Westby wrote:
> > I still think finding ways to have contributors forward the patch before
> > seeking sponsorship will improve the situation. Clearly my suggestion
> > wasn't going to get very far, but I'd love to discuss any ideas that
> > anyone else has.
> 
> Well, one idea I've batted around is not so much to change the
> sponsorship process, but to augment it with tools that come into play
> when a patch is uploaded.
> 
> 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.

This is an interesting idea, but seems like it would take quite a lot of                          
resources and would be kind of fragile. The kind of issues that come to mind are:                 
  * Somebody puts up a OO.o or kernel patch, we're utilizing a lot of CPU                         
    resources for a relatively low rate of return. We'd perhaps have to work out                  
        a good queue structure.                                                                   
  * Often people upload patches based on the current stable version of the                        
    package, which may not apply cleanly.                                                         
  * Often people upload patches that are not against the root of the source                       
    tree, we might have to play around with patch -p to get it to apply cleanly.                  
                                                                                                  
The nice thing about your proposal is that would allow us to fairly easily                        
identify "good" patches. There are currently 1817 patches in Ubuntu bugs                          
according to Launchpad. I doubt there are all that many that are real patches                     
that apply and build cleanly, but it sure would be nice to know which ones do                     
:-)                                                                                               
                                                                                                  
I think as a first step we need an automated way to identify true patches                         
though. It would really be a big help no matter what we do. The current patch                     
flag system is really not working well (and hasn't for some time, if ever).                       
                                                                                                  
-Jordan