[Pixman] Giving out commit access

Søren Sandmann soren.sandmann at gmail.com
Tue Jun 12 16:08:59 UTC 2018

> Traditionally this project has been extremely conservative.

That depends on what you mean by "extremely conservative". When the pixman
git repository was originally set up, everybody with commit access to cairo
and xorg got commit access to pixman as well. All of these people still
have commit access as far as I am aware. So lots of people have the
permissions to make changes to the pixman repository.

But if you mean "social" commit access, pixman has indeed been strict about
requiring review and about keeping the bar high for code quality.

I don't know if they were widely know, but the rules were that if you had
commit access, then you should send your patches to the mailing list, and
if you got no response for a couple of days, you should feel free to push.
In practice this meant that Siarhei, Matt and I had commit access after
sending patches to the mailing list. Patches from everybody else would be
reviewed thoroughly.

Setting a high bar for code quality was a result of my experience with the
code: Pixman was created in 2007 as the merging of a three-way fork of the
Render parts of the X server framebuffer code, one from cairo, one from
Keith's X server, and one from the Xorg xserver. All of these forks had
acquired lots of garbage code, and the merged pixman had merged all that of
that and itself become garbage. Lots of this garbage had been written by
well-known names in the community (and yes, a good chunk of it had been
written by me).

When I say "garbage" I mean code that simply didn't work, and only worked
in the one case that the author cared about when writing the code. I don't
mean formatting or minor code structuring issues. This basically still
applies, although today there is perhaps a handful of people I would trust
to write good pixman code. This is not unique to pixman btw. The X server
project also moved away from a free-for-all to a model where Keith is the
final arbiter of what goes in. And of course the kernel has always done

As an example, one of the first contributions to the merged pixman was
another mountain of garbage ARM code that went in without much review. This
code simply didn't work - it had memory corruption issues and did handle
premultiplication right. It also had various arithmetic bugs. (Siarhei and
Ben Avison have since then written high-quality ARM backends).

The lesson for me was that most people simply could not be trusted to write
decent pixman code, and that all patches therefore had to be carefully
reviewed before going in.

The result of this policy is that pixman is now remarkably bug free and
stable compared to almost any other open source library, and that the few
recurring contributors that pixman got are all extremely good. But the
downside is that pixman possibly did not evolve as quickly as it could
have. and that I eventually burned out reviewing all these patches.

If pixman will now be turned into a free-for-all again, the risk is that it
slowly turns back into a mountain of garbage. I don't know if that is
better than being stable, bug free and moribund.


On Tue, Jun 12, 2018 at 3:29 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> Hi,
> what are the criteria to give out commit access to Pixman?
> As I could give access, I should probably have an idea when.
> I see Maarten already got his, and there is another asking for it,
> but no discussion about them at all that I remember seeing.
> Traditionally this project has been extremely conservative. Are things
> finally changing? Does someone have some great plans to revitalise the
> project?
> Thanks,
> pq
> _______________________________________________
> Pixman mailing list
> Pixman at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pixman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pixman/attachments/20180612/6dcf1b36/attachment.html>

More information about the Pixman mailing list