Re: gobject-performance

On Thu, 2009-09-24 at 15:37 +0200, Benjamin Otte wrote:
> Hi,
> I'd like to move the work done on the gobject-performance branch to
> master now that 2.22.0 is out. It contains tremendous improvements for
> threaded applications and even noticably speeds up non-threaded
> performance. The patches on the branch have been developed, reviewed
> and tested by at least Alex Larsson, Edward Hevery and me, so it
> should be sufficiently reviewed.
> I'd have liked to get Tim to review it, but he seems to be quite busy
> now and IMO we threw enough eyes and CPU time at the issue to be sure
> there is no regressions. (From the tests we added, I'd even say it's
> more stable than master).
> I'd also like to get it merged while we're far away from the next
> release, so it gets enough testing, as these changes are quite deep
> down the stack and we want to find remaining issues with them before
> we release the next stable.
> So can we merge the branch or is there anything that we should take
> care of before?

Man, this situation with such low maintainer activity in gobject is
getting out of hand. We really need a way to get important fixes like
this into gobject in finite amount of time. After all gobject is the
core of the whole gtk and gnome platform, if we can't get fixes into it
then we're in a very bad shape.

I realize that GObject is a very complex and important piece of software
and that timj knows it much better than anyone else. However, we just
cannot totally stop work on it when timj is busy with other things.

Now, some stuff in the gobject-performance branch is pretty trivial, but
some of it is extremely complex (lock free stuff, atomic refcounting
etc), so I don't really like to just "wait a bit and then commit without
timj approval". However, I'd like to have *some* way of getting things
in, while still having a decent chance of finding problems before they
land in glib.

What about introducing some sort of ack rules. If you can get, say,
three detailed reviews with acks from well known developers (core
people, maintainers, etc) then we can commit stuff during to the
unstable branch.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]