[cairo] Should cairo support xlib? (was: bug 4945: six months to
fix a bug ?)
cworth at cworth.org
Fri Feb 2 08:36:59 PST 2007
On Fri, 2 Feb 2007 09:31:25 +0100, "Eric Faurot" wrote:
> On 2/1/07, Carl Worth <cworth at cworth.org> wrote:
> (I also changed the title to focus on the real issue)
There. I finished the change for you so you can get some of the impact
> The problem is not about cairo supporting pseudocolor or not. It is
> about cairo supporting xlib or not.
OK, fine. We really don't need to debate the "why" of the patch at
all. We would both like to see it fixed, so let's focus on what needs
to be done to get there.
[cool, that lets me drop a lot of the debate...]
> Well, you have the patch, you have probably guessed how it works, and
> I am already maintaining this patch, as far as OpenBSD is concerned.
> The only problem is that I am not interested in maintaining it as part
> of cairo itself.
I have the patch you sent to this list on March 27. Is that still
> Yes, there is support burden. This is the price you pay when you
> maintain something successful, and on which many other people depend.
> That is why I wrote that patch, when I felt personally responsible of
> my cairo port resulting in a gtk regression that required to backout
> the whole gtk update just before an OpenBSD release.
There is one practical point that should be made here. The fact that
OpenBSD accepted this patch really took a lot of pressure (or
potential pressure at least) off of the upstream projects here.
You and Marc have said quite clearly that you have a lot of users that
care about this issue. You have also pointed out that even if the
"bug" vs. "missing feature" question is open as far as cairo is
concerned, that GTK+ definitely suffered a big regression when it made
the switch to start depending on cairo, (without support for 8-bit
So, when you've got a lot of users that would be affected by a
regression in an important package like GTK+, that sounds to me like
an opportunity to apply that pressure to improve GTK+, (which could
have, in turn, fixed this in cairo---which, as you said, is really the
only place to fix the issue). But when the distribution masks the
issue, all that good pressure-to-improve just disappears.
For example, when you sent your patch on March 27 of last year, you
Please test and report, especially those who are stuck with 8 bit
I was really hoping to see some replies to that, showing that people
had tested it and it worked for them. As it was, the patch came with a
lot of disclaimers about performance and quality, and didn't get any
replies on the list.
So, it would have been nice to actually see people that were affected
by the issue get involved at that point. And that definitely could
have helped move things forward then.
But anyway, that's in the past now.
> I don't want to do this for the following reasons (which might also
> give you some possible idea on how to attract developers):
OK, let's work this out. I think this should actually be quite simple:
> - I don't want to be forced to use git
Feel free not to. What would be perfectly fine at this point is to see
a complete patch generated from the 1.3.12 snapshot. And for future
major releases, it would be great to get at least one positive test
report during the series of experimental snapshots leading up to the
I'd be glad to accept emailed patches against the latest snapshots and
integrate them with git. I don't have any problem doing that work.
> - I don't want to be forced to use bugzilla
Please ignore it then. I personally can't stand bugzilla. I think this
mailing list works much better. Just take a look at how much more
action we're getting on this issue with this thread than with a
> - I am not interested in contributing to a (L)GPL project.
That one I can't help you with. Do you mean you're not interested in
sending any patches for use in cairo under its existing license? If
that's the case, then I'm not sure why we're even having this
> - I don't have time to follow cairo development
That's fine. I understand that cairo's not your primary
concern. Fortunately I don't think the maintenance burden we're
talking about here is actually all that large. Would you be OK if I
emailed you in advance of major releases, (currently that looks like
no more than about twice a year)? Also, could I email you in the
occasional situation where we have to modify this code and might have
If you're willing to own the code in that fashion, that's fine with
me. I would imagine this really isn't more work than you're already
committed to do to maintain the patch within OpenBSD.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070202/092fb79a/attachment.pgp
More information about the cairo