[cairo] Should cairo support xlib? (was: bug 4945: six months to fix a bug ?)

[Marc Espie]

On Sat, Feb 03, 2007 at 07:45:43PM +0100, Eric Faurot wrote:

> No, my latest patch is against 1.2.6.  See the attachment.

> I have tried it on amd64/nvidia, macppc/ati and macppc/wsfb (openbsd
> framebuffer), at 8 16 and 24 bit depth, with and without RENDER, on
> local X and through ssh.
Trying it out on i386/ATI myself...

> It does not work on local X for depths 8 and 16 if RENDER is enabled.
> Disabling RENDER works everywhere.  The strange thing is I was almost
> sure it worked with an older patch.  I need to enable the workarounds
> even if RENDER is available.

This is a bit worrysome, especially for depth 16. There are cards out there
which need that...

can you fix that promptly ? Otherwise we won't ship cairo 1.2.6 in 
OpenBSD 4.1.

> Then I'd suggest that you, as the project leader, just shutdown this
> tracker.  It is obviously affecting communication and it is diluting
> efforts.  That is just my opinion, but I really suspect this awful
> piece of s....oftware is actually discouraging many people from
> reporting and contributing useful things.

Let bugzilla stay. At least it doesn't actively hinder development (as
compared to some other projects I know, where you can't do anything without
having to actually go through bugzilla).

> Actually this point is just one aspect of the general time issue.  I
> like cairo, but when I choose how I spend the free time I am
> dedicating to free software, the license thing is also part of the
> equation.  Now for my patches, of course I'd be glad if they were
> integrated into cairo: improvement for cairo, wider audience to get
> feedback, less work for me, helps everybody.  It is a win-win
> situation.

Well, there is the harsh fact that there currently is no cairo-equivalent
under a BSD licence or similar. That's how we all end up contributing to
various projects. Even though they're not perfect, they are the only game
in town. And you've got to admit, LGPL beats proprietary software, every
time.

> All of this sounds fine.  Now, to explain the "compromise" I was
> talking about.  My work on cairo is currently following the OpenBSD
> schedule.  I take whatever the latest stable release is when needed,
> patch it and package it.  Now that would mean I must follow the cairo
> release cycle too, including experimental releases.  I can do that if
> it is not too costly for me, and if that does not mean completely
> rewriting my unclean patch by myself. About the patch itself, I needed
> something simple that would fix the problem right away, based on the
> stable cairo release that we ship, without having to spend too much
> time on it.  Nice design and efficiency is obviously not a priority
> for me.  My goal is simplicity and correctness.

In my opinion, the best way to follow the OpenBSD release schedule is
to be prepared in advance. If you follow cairo development a bit more
closely, then whenever cairo releases, whatever comes out works on OpenBSD,
first time, without needing any patch. That's how I've been handling KDE
for ages now. Works like a charm.

> What I don't want to do is:
> 
> - provide fixes for every stable and experimental cairo releases if it
>  is not getting anywhere.

Well, getting the patch integrated ensures that you won't have to.
Assuming cairo has one -stable branch (1.2.6 ?) and one -devel branch (1.3.x),
all you have to do is make sure your patch gets in both branches (with some
help from the cairo people).

Then you may just need to catch up from time to time.

It's a fairly small price to pay. To open a comparison, this looks a hell
of a lot easier than GCC contributions, where they don't accept contributions
to the stable branches, where you have at least 3 or 4 branches open at one
time, where the rules to get something important in are decided by a committee
who takes at least two months to give you a decision, where you have to wait
for enough weeks to get a patch approved that you often have to reroll the
patch because the stuff you wanted to affect was moved in-between, where
you often have to rewrite a patch because it misses one space before a comma
or the Changelog entry is not 100% perfect, and where you're often stranded
because the -current tree you should test on happens to not compile on
anything at the moment besides i386-linux-gnu because of some H.J.Lu's recent
patch that he hasn't had the time to revert yet. Oh yes, and once your patch
is in, you know that it's probably going to be at least one or two years 
before it trickles down to a -stable release...