Re: Cairo-1.2.6 required

["Elijah Newren" <newren gmail com>]

On 1/23/07, Carl Worth <cworth cworth org> wrote:
> What's "far enough ahead of GNOME 2.18.0" mean precisely?

It doesn't have a precise meaning, actually.  It's basically "GNOME
2.6.0 was burned by depending on GTK 2.4.0, which was a low-level
library not on the GNOME release cycle and released far too close to
GNOME 2.6.0; we should avoid a repeat of something similar to that."
See http://mail.gnome.org/archives/gtk-devel-list/2005-June/msg00109.html
for more details.  Actually, I guess I can give a precise meaning:
"the majority of the release team members who comment on the issue are
comfortable with it."

> As for upstream cairo plans, we have been working to have a cairo 1.4
> release that GNOME could pick up for 2.18. Back in mid November, (when
> the first big wave of cairo performance improvements landed), we
> talked about when 1.4 should happen, looked at the GNOME 2.18 roadmap
> and guessed that if we got 1.4 out in January 2007 that GNOME would be
> able to pick that up. So that's what we've had on our roadmap since
> then:
<snip>
> So how does that status look compared to what GNOME 2.18.0 needs?

Looks fine to me, and Kjartan's already in favor.  Others (Kalle,
Matthias, Behdad) have already voiced their support and I haven't
heard any dissenting voices, so sounds like it's an easy decision to
make right now.

> And in the future, how can cairo work more closely with GNOME to
> coordinate things like this? For example, you said nobody had proposed
> cairo 1.4 for GNOME 2.18. How do those proposals happen? Should that
> be us from cairo making the proposal?

> From you or gnome module maintainers using cairo.  :)

> What I think I would love to see is GNOME saying to cairo, "We've got
> a 2.xx release coming up, and we'd love to see a cairo that had A, B,
> and C in it for that. We'd need that by month Quintilis.  Doable?".
>
> Think we could get something like that out of GNOME release planning
> sessions?

Possibly, but it sounds like a stretch.  We have well over a hundred
modules + external dependencies in the release set.  It'd be difficult
for release team members to be expert enough in all of them to
generate such an expectation list for each and send them to every
module.  It'd be much easier to generate expectations for cairo by
talking with the cairo maintainers.  I think relying on the cairo
maintainers or module maintainers making use of cairo to start such
conversations is the most reliable way to make sure they happen.

I know, the new external dependency handling[1] is still a bit new to
everyone and we're having some hiccups incorporating it, but it has
done wonders for buildability of the stack and for helping various
teams to stay on top of things.  Any suggestions at further
improvements to the process are welcome.


Cheers,
Elijah


[1] Summarized version of the change in rules: new versions of modules
must be explicitly proposed in order to increment the dependency
instead of having letting any person bump the dependencies at any
time.  Full details are available at:
http://live.gnome.org/TwoPointSeventeen/ExternalDependencies