[cairo] 1.10 release schedule

[Chris Wilson]

On Tue, 12 Jan 2010 20:32:44 -0500, Behdad Esfahbod <behdad at behdad.org> wrote:
> On 01/12/2010 08:11 PM, Carl Worth wrote:
> > I'd like to help fix that, and will be happy to jump in and do what I
> > can here. I'd also feel fine if Chris wanted to take the
> > release-management task on himself. But I know that when I was doing
> > most of the cairo development, I often wished there was someone else to
> > say "No, it's too late for that code. It's time to release." So, I'll be
> > glad to be that "someone else" for Chris now if that would be useful.
> 
> If you can be forced to do that, I'd really love to see you just do it since I
> think you're a great release manager (even if your reverts have left some hard
> feelings in me ;) ).  Failing that, I'd suggest Benjamin or Joonas (in that
> order) do it.

Agreed, I'm much too attached to my code to make an objective judgement
on what should go into the release. I have so much that I want to get into
a new stable release, and still too many ideas for investigation.

> 
> [snip]
> 
> > I don't know if regular 6-month (or 12-month) releases would be better
> > for cairo. But it's clear that no matter how soon we release cairo 1.10
> > it will have been a longer delta than anything previous.
> 
> It also is kind of a sign of maturity.  I think our biggest failure this cycle
> was NOT not getting 1.10 out "on time".  It was not getting a next 1.8.x
> release out.

Again, my fault. I've 6 patches in the 1.8 branch and had intended to do a
release months ago.

> > I definitely want to use cairo's current master branch as the basis of
> > the new release, and get things in releasable shape as soon as possible.
> > 
> > That can mean that cleaned-up portions of Chris's giant branch can land,
> > but I don't want to commit to necessarily having it all land.
> 
> Lets move in the "only bug fixes in" mode already.

There's a number of small things that can be pulled from wip/compositor to
address bugs in master, and a commitment we made to providing interfaces
for gstreamer. And my intention is to refactor that branch such that I can
apply those and introduce the additional core tools and add the new
backends without affecting the existing ones. Then we can decide whether
the performance gains from rewriting the existing backends and removing
support for surface-fallback is worth it.

What would seem a sensible step would be to only have the release manager
make commits to master at this point.
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre