[Pixman] Is Pixman being maintained at all?
oded.gabbay at gmail.com
Thu Jul 16 06:38:27 PDT 2015
On Tue, Apr 7, 2015 at 10:19 PM, Matt Turner
<mattst88-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> 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.
>> 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
> 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."
> 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.
> Pixman mailing list
> Pixman at lists.freedesktop.org
Hi Matt, Siarhei
As you probably already know, my name is Oded Gabbay and I'm working
at Red Hat Desktop graphics team, and my current focus is on ppc64le.
During the last couple of months, I've been working on adding support
for ppc64le to pixman (fixing vmx fast-paths and adding new
implementation). Some of the patches have been upstreamed (by Pekka
Paalanen) and some are in the process of review (by Siarhei and
>From reading the above email thread, and from talking to Soren, Pekka
and others, I understand you may need some help, in terms of time and
resources, for actively maintaining pixman (last release was 1 year
If that is indeed the case, I would like to offer my help to make
regular releases for Pixman, both for upstream and Fedora, as well as
do bug-triage and code reviews.
I believe I have the available time to do it as I'm working 100% on
graphics in Red Hat. In addition, as a Red Hat employee, I have the
resources to build/test pixman on multitude of architectures, and use
Fedora build system as well. moreover, I'm already the maintainer of a
fairly large kernel gpu driver (amdkfd - upstream since February), so
I have maintainer experience.
So far I had already helped Pekka clean the patchwork site he setup
and I will continue to make sure it is updated. In addition, I got
packager role for pixman in Fedora, so I'm able to release new
Waiting for your response. Feel free to express your opinions - I
already have thick skin from the kernel work ;)
More information about the Pixman