Bugzilla Patch Collision

Edit: I was told that a similar feature was already planned for DXR. I think DXR as the potential to be a very good development tool!

I have been discussing this idea a bit over the work week and though I should perhaps get a better opinion. I haven’t worked on very many patches yet so I might be going from a small sample size but it seams like it should be possible to know if anyone is modifying the same code you are. I would be interested to know how common this problem is to everyone else so please let me know!

What I suggest is to have a separate web app from Bugzilla that would keep a copy of all current patches. You could submit your patch to that server and the web app would present you with a report of all patch that touch the same source files and even highlight patches that directly conflict with your patch. A visual diff of all the patches on a given source file would be a great bonus (color coded like EtherPad). It could also show you information about the review state of that patch (if its been super-reviewed and is likely to land soon). An added benefit is you could query the server if an existing Bugzilla patch can no longer be applied on Trunk (bitrot).

I’m curious to know if people that have been using Bugzilla longer think it would actually be worth while to create this tool or if it would just become an annoying optional step when submitting patch?

4 thoughts on “Bugzilla Patch Collision

  1. Why have a submission step? You could have the tool automatically search for and download all new patches using the BzAPI, work out what files were touched, then notify Bugzilla (by adding a comment?) if that patch conflicted with other recent patches.


  2. Well I would see value in manually reviewing the information instead of relying simply on detecting ‘absolute’ collision. Changes applied elsewhere could break something you are invoking for example. Or they may just provide a better understanding on how the file will involve.

    This doesn’t exclude us from having automated comment like you suggested.

  3. One reason to involve a process outside of the bugzilla interface is that determining what revision/repository a patch is against can be troublesome. I have encountered this in my review board work.

    Some patches include their base revision id, but someone just uploading an mq patch from their .hg/patches or a git-diff is not going to include that information. And even when that information is included, it can be useless if their patch is on top of a patch which has not been pushed to a public repository known to the tool.

    I’ve been thinking that building on the push-to-try model may be the way to go. Someone pushes their patch and points the tool at the revision of interest.

    The review board tool has the ability to think of both a patch under review and a patch it is built on top of. This concept seems useful to maintain, although I think your proposed tool could only say “hey, your patch under review no longer applies” or “hey, the base patch your patch depends on no longer applies, so I don’t know what this means for your patch.”

    I think this would be a great tool and have indeed dreamt of such a thing too! It would be super-awesome to have this (and also advance the state of patch understanding to assist in reviews.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s