On 1/23/07, Carl Worth <[EMAIL PROTECTED]> 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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
