On Thu, Apr 2, 2015 at 2:26 AM, Pekka Paalanen <[email protected]> wrote: > On Wed, 1 Apr 2015 18:46:10 -0700 > Matt Turner <[email protected]> wrote: > >> On Mon, Mar 30, 2015 at 10:58 AM, Bill Spitzak <[email protected]> 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. _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
