Discussion:
[Pixman] Giving out commit access
Pekka Paalanen
2018-06-12 07:29:00 UTC
Permalink
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
Adam Jackson
2018-06-12 13:59:31 UTC
Permalink
Post by Pekka Paalanen
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?
I wouldn't say I have a grand vision, but it's also been actual years
since a release. "Moribund" might be a better word than "conservative"
at this point. Certainly if someone _does_ have some interesting
project in mind it's worth hearing about, but right now my primary
interest is that pixman see enough maintenance that xserver keeps
working.

I think probably the answer to the vision question will determine the
answer to the commit access question. I'm generally pretty liberal
about granting that kind of access, but I'm not the only stakeholder
here, just trying to get something moving.

- ajax
Søren Sandmann
2018-06-12 16:08:59 UTC
Permalink
Post by Pekka Paalanen
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
this.

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.


SÞren
Post by Pekka Paalanen
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
https://lists.freedesktop.org/mailman/listinfo/pixman
Pekka Paalanen
2018-06-13 08:02:37 UTC
Permalink
On Tue, 12 Jun 2018 12:08:59 -0400
Post by Søren Sandmann
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.
Hi SÞren,

that is very valuable input to the discussion. I wouldn't propose to
make Pixman free for all or merge after review timeout even for chosen
developers. In my experience lack of review bandwidth is a problem.
This is the same for pretty much all projects I'm involved with.

I would hope there would appear two people with commitment to dedicate
some time for Pixman and spar each other to gain the knowledge needed
to keep Pixman bug free and stable.

Since gitlab CI is a thing, maybe a first priority would be to set up
as many different architectures to run the existing test suite as
possible. The very least there should be a single big-endian system in
that set. I have the feeling that writing and reviewing Pixman patches
is hard because of the variability in the supported architectures
coupled with low-level code.

There is a movement in gfx community to give out commit access easily,
and that is predicated by having the rules written down: how to ensure
sufficient patch quality during review, and what are the rules to give
out commit access (usually involves some sort of track record of good
quality contributions).

However, I feel that we need to bootstrap the Pixman community, because
the accessible review bandwidth is currently (well, 2-3 years ago when
I was somewhat involved) very thin. Hence the idea of two people to
avoid starvation. Maarten, are you one of them? :-)

Btw. about commit access: should we perhaps disable the "ask for
access" feature in gitlab and instead handle that through Issues so
that the discussion gets recorded?


Thanks,
pq
Emil Velikov
2018-06-27 12:26:17 UTC
Permalink
Hi Pekka,

Have you considered reusing the wayland commit access/review criteria ?
Personally it seems that using it as a draft, could be fairly good start.

Quick look at a Ubuntu machine shows multiple users of pixman, so
keeping it alive is a worthy goal.
- xservers - xorg, nested, wayland, ..., tigervnc
- qemu, spice
- cairo
- libweston
- odd bits - notify-osd, gtk2-engines-murrine, texlive-binaries,
kylin-greeter...

HTH
Emil
Pekka Paalanen
2018-06-27 12:42:31 UTC
Permalink
On Wed, 27 Jun 2018 13:26:17 +0100
Post by Emil Velikov
Hi Pekka,
Have you considered reusing the wayland commit access/review criteria ?
Yes, I have, but I need to get it into shape first. :-)
It's in my mental todo list to at least point to it as an example of
what we might think for Pixman.


Thanks,
pq
Post by Emil Velikov
Personally it seems that using it as a draft, could be fairly good start.
Quick look at a Ubuntu machine shows multiple users of pixman, so
keeping it alive is a worthy goal.
- xservers - xorg, nested, wayland, ..., tigervnc
- qemu, spice
- cairo
- libweston
- odd bits - notify-osd, gtk2-engines-murrine, texlive-binaries,
kylin-greeter...
HTH
Emil
Continue reading on narkive:
Loading...