Getting xserver patches reviewed

Wichmann, Mats D mats.d.wichmann at
Mon Nov 26 22:03:52 PST 2007

xorg-bounces at wrote:
> Daniel Stone writes:
>> On Mon, Nov 26, 2007 at 10:27:42AM -0800, Alan Coopersmith wrote:
>>> Bernardo Innocenti wrote:
>>>> There are a bunch of older xserver and libX11 patches
>>>> that I submitted to the xorg@ list, which went mostly
>>>> ignored for a very long time.
>>> When developers have time to review patches, they usually look
>>> in bugzilla, not the mailing list archives, since it's much
>>> easier to search there and find which patches have been applied
>>> (and thus the bugs closed) and which still need to be reviewed.
>>> Make sure to include the keyword "patch", so it shows up on the
>>> list of outstanding patches at:
>> Actually, to be honest, I usually only find myself with time[0] on
>> planes, trains, and, er, buses, which rules Bugzilla out. I do a
>> search for [PATCH] through xorg@ and review all my flagged mail, and
>> I try to flag interesting patches. 
> I'm in a similar situation. This however doesn't invalidate the notion
> to aslo submit a patch to bugzilla is a good idea.
> Bugzilla allows to go back and find the motivation behind a patch
> (along with the discussion that led to it).
> It is easily trackable as the bugID in the Changelog is sufficient.
> We used to have the policy to submit a patch to bugzilla before
> applying it when CVS was still around.
> For some reason people thought this to be unnecessary after
> modularization and the change to git had taken place.

I use an offline bugzilla client called deskzilla for this
(you still have to kick it to download attachments, which it
doesn't just do automatically, there's probably a setting
somewhere I can tweak). This helps with the "I've got a few
minutes but I'm not on the internet" problem. deskzilla is not
free, but they'll give free licenses to OSS developers. I think
there's a free offline bugzilla thing floating around too.


There are other methods that can be applied here too, however.
Purely as an example, the Bazaar project uses a "gatekeeper" 
process, called PQM (patch queue manager) to merge changes to
"official" branches.  PQM can apply defined requirements, such
as "pass regression test", "compile without error", etc. before
passing the merge through the gate.

This is front-ended by something called BundleBuggy, which collects
merge requests in the form of patch-like things, and presents
an interface where they can be voted on; discussion goes to a
mailing list.  With enough votes, the merge is sent through.
The past history is kept, so you can always go back and review
the patch and any attendant list discussion.

Just some fodder for thought....

More information about the xorg mailing list