[cairo] Cairo 1.9 now open for business on master

Carl Worth cworth at cworth.org
Thu Oct 30 09:01:18 PDT 2008

Thanks for the 1.8.2 work! Well done, everybody!

Cairo master is now 1.9.1 and open for new features.

We expect to maintain "0 failures" for the test suite. Start using XFAIL
for bugs instead of FAIL.

A new 1.8 branch is open as well.

For "bug-fix only" commits for bugs that existed in 1.8.2, commit to 1.8
instead of master, and then merge 1.8 into master.

More details below.


A big thank you to everyone for helping with cairo 1.8.2. It's
definitely our best release ever. It's really pleasing to me to see so
many bugs get fixed---particularly some bugs that have been languishing
for a long time. So thanks to everyone for your patience as new-feature
work was queued up and had to wait.

I'm happy to announce that the waiting is now over.

When you do your next "git pull" you'll see that cairo's master branch
is now calling itself 1.9.1 and this branch is now open for new
features. I know lots of people have stuff ready to go, so it should be
an exciting time as we start landing this stuff.

Of course, this isn't an excuse to start landing unfinished code. I
trust everyone to continue to post new code to the list for review
before pushing it. And, during the 1.8.2 series we did a *lot* of work
to get the test suite into very good shape. I want to keep it very
clean, and I'll get really grumpy if it starts getting messy.

I plan to update the instructions in test/README soon, but here are some
comments off the cuff.

The test suite is in very good shape now. On my system, with Xvfb
running on :2 I can do:


and get 0 failures[*]. We've even documented in test/README what people
need to do to get the same results. So it would be great for all cairo
developers to first ensure that they can also get 0 failures from the
test suite. If not, let us know and we'll help fix whatever needs to be

[*] Testing svg12 does show several failures. It's a high priority to me
to get these fixed soon, and to not exclude it from testing. But for
now, people should ensure they can get 0 failures while excluding svg12.

At that point, the test suite is useful again for people to ensure that
new code they write doesn't break things. The expectation is that people
will run the test suite as an additional verififcation before pushing
code, (it doesn't eliminate the need for code review of course). And
hopefully we'll see Vlad soon announce some automated systems for
running the test suite for us.

Now, in the past when we've identified bugs, we've added new test cases
that would FAIL for the bug. I think I'd like to start getting in the
habit of doing XFAIL for such bugs. That way, people can still see the
"0 failures" result and trust that their own code didn't cause any new
problems. With this, I'd also like the HTML report to not hide away the
XFAIL images anymore. Every XFAIL is a bug we need to fix. And of
course, when you do add any new XFAILS, please document the bug in the
Makefile where the others are listed.

Finally, I've also added a new 1.8 branch. It's hard to know exactly how
this branch will get used, since we don't know what bugs will be found
in 1.8.2 nor how long until 1.10.0 is ready. Here is my recommendation:

If you are making a commit that's a bug-fix only, not a new feature, and
if that bug existed in 1.8.2, then please make that commit on the 1.8
branch rather than master. Then you can merge 1.8 into master so that
the bug fix is available there as well. If everyone does this, this will
help the person eventually making a 1.8.4 release to do it with much
less effort. So here's a recipe for that:

	# Code up a bug fix
	git checkout 1.8
	git commit -a
	git checkout master
	git merge 1.8
	git push origin

At some point, master and 1.8 could diverge enough that this merge
approach won't be feasible anymore. At that point, we might have to go
to double committing, or cherry-picking or backporting, etc. But
hopefully, by that same time we'll be ready to push 1.10 out the door
and make a new stable branch.

So let's give this approach a try and see how it works.

Happy hacking on cairo!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20081030/1640c21f/attachment.pgp 

More information about the cairo mailing list