[Pixman] Is Pixman being maintained at all?

[Matt Turner]

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.