[Pixman] Is Pixman being maintained at all?

Matt Turner mattst88 at gmail.com
Tue Apr 7 12:19:30 PDT 2015

On Thu, Apr 2, 2015 at 2:26 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 1 Apr 2015 18:46:10 -0700
> Matt Turner <mattst88 at gmail.com> wrote:
>> On Mon, Mar 30, 2015 at 10:58 AM, Bill Spitzak <spitzak at gmail.com> wrote:
>> > On 03/30/2015 10:25 AM, Matt Turner wrote:
>> >
>> >> Do you just need someone to push them?
>> >>
>> >> I'm not capable of reviewing these.
>> >>
>> >> Since Søren isn't really maintaining pixman anymore I'm not really
>> >> sure how to proceed.
>> >
>> >
>> > Is this true?
>> I don't see anyone but Pekka reviewing patches and there hasn't been a
>> release in 15 months, so yeah.
>> > I think something needs to be done about this as all new work on X and Cairo
>> > is depending on pixman.
>> I mean, sure.
>> > I have had an outstanding patch set for 8 months now. Søren responded to an
>> > earlier version and I tried to address it but have not heard anything since.
>> > This is very frustrating as I would like to work on this but I'm not going
>> > to do it if it is useless.
>> As far as I know, Søren isn't working at Redhat any more, so I don't
>> think you can expect him to continue maintaining pixman.
> Ok.
> Søren, Matt, Siarhei,
> how can we get the Pixman maintenance communitized? Maybe a la
> libdrm, because no-one has the resources to become a dedicated
> maintainer?

Seems fine to me, though I don't really feel like a pixman maintainer. :)

> What does it take to get push and release authorization, in the
> political sense that Pixman quality would not degrade and the
> current/old maintainers would approve?
> What kind of review policies should be enforced?

Søren told me back in December on IRC "Feel free to do a release".

I'm happy to have people commit to pixman who have a track record of
contributions to other X.Org projects.

> What development guidelines should there be? Should it be strictly no
> new API/ABI nor features, only performance work and new platform
> support like the latest new ARM?

I'm not aware of any backwards-incompatible changes to pixman, at
least in a really long time. Keeping that policy in place seems like a
good idea.

New APIs do happen. I think that's probably fine.

> If there is one person contributing arch or cpu-specific optimizations
> in assembly that no-one is willing to review apart from the scope of
> code changes and style, should we trust that one person and just land
> his work if he shows the performance numbers are good?

I might be a bit biased in my answer, since I have some patches to the
MMX code in my tree that I don't expect anyone to review, but yeah I
think we should mostly trust the author (obviously depends on the
author's credibility).

> I mean, I'm a newbie here. I don't want to hijack this project and push
> it only to my own directions, also because I cannot become a dedicated
> maintainer, nor promise to review anyone else's stuff. But, there are
> patches I'd like to see landed. I could work on them with Ben, but if
> there is no-one "upstream" to tell us what goes and what doesn't, we
> are left to our own judgement. Would you trust my and Ben's judgement
> so that I could land Ben's patches and make Pixman releases?

I don't think you're hijacking at all. I think this conversation
needed to happen sooner or later, though I do wish Søren or Siarhei
could spend a little time on it.

> You probably don't have a good understanding about how I work and what
> kind of a developer I am, nor have that kind of trust in me. That is
> fine. We need time to build that trust through discussion and patches.
> But it's hard to have a discussion if no-one can reply. I also
> understand that because I will not promise to be a maintainer, there is
> less incentive in educating me. It is quite likely that I hang around
> here for a while and then wander off when my needs are filled.

I haven't worked with you, but I'm familiar with your contributions.
I'd trust you to commit to pixman.

But I don't think I could really educate anyone except in the MMX and SSE2 code.

> The same goes for everyone, I believe.
> What could we do to let Pixman go forward?
> I suppose a project in a similar state would just get forked by some
> new people, who will then drive it with their own goals. Except here
> that doesn't work, because the fork would soon fall into the same state
> as the original project, except the world would just be more
> fragmented. Couldn't we as well just loosen up on the master branch and
> let stuff land whenever someone is active and someone else doesn't see
> anything bad in it? There are always the stable branches, too, for
> those who want to stick to old and well-tested code.
> Yes, the software quality will likely degrade somewhat, at least from
> the old maintainers' perspective. However, the alternative seems to be a
> completely stalled project. Which one is better?
> FWIW, distros (well, Raspbian at least) already maintain their own
> forks, most likely as a single-person project. At upstream we could at
> least aim for a different person to review a change than the one who
> wrote it. For distribution users, that should be a win, along with
> gathering development into one place.
> Am I asking for your approval to get push rights to Pixman upstream?
> Hmm, I suppose I am. At least that would make me personally responsible
> for the stuff I push, without having to piggyback on someone else who
> might then fear getting unjustified blame.
> I will certainly reserve the right to say: "No, I won't push that,
> because I can't tell if it is good for Pixman or not."
> Thanks,
> pq

Yeah, short of a maintainer reviewing things, I don't see many options
other than opening up commit access to more people. How exactly people
build credibility to the point that they get commit access without
someone reviewing their work... I don't know.

So, I think you should get commit access. :)

So far, I'm aware of

- Ben's ARM optimization patches
- Bill's patches
- I think Nemanja Lukic still has some outstanding patches
- I've got a few small things

If you're happy with Ben's patches, I don't think we should block them.

I don't know how Cairo does review, but I think it would be really
nice if a Cairo developer reviewed Bill's patches (I think they were
adding a new API to pixman?) if not for all the little technical
details but that the API makes sense for its uses in Cairo.

I'm not sure where Nemanja's patches stand.

More information about the Pixman mailing list