[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GNOME 2.32 plans



Hi,

On 04/08/10 10:24, Josselin Mouette wrote:
> as some of you might have heard, there is going to be a GNOME 2.32
> release in September, GNOME 3.0 being delayed to next spring.
> 
> For a large number of modules, 2.32 is going to be a pure bugfix release
> based on 2.30. Therefore I propose the following approach:
>       * For bugfix releases, we upload them to unstable and try to put
>         them in squeeze.

This sounds a little error-prone, but I don't have a better idea than "let's
just release with 2.30", so I'm fine with it. (If we upload something that
shouldn't have been uploaded, we can always reupload the 2.30 package).

>       * For modules requiring GSettings, we keep the 2.30 version, maybe
>         with some backported bugfixes. GSettings is simply too fresh, we
>         don’t have enough hindsight and we don’t want to have to direct
>         users through 2 different configuration mechanisms.

Agreed.

>       * For modules not requiring GSettings but requiring other new
>         features in Glib or GTK+ 2.x, see later. I doubt we will have
>         many such modules.

> Then there’s the case of Glib. Glib 2.26 will be backwards compatible,
> but the introduction of GSettings causes some packaging changes. I’m not
> too fond of risking to break reverse dependencies. Having this version
> in squeeze will depend on the calendar, but I’m not too fond of risking
> to break thousands of reverse dependencies. I guess we’ll have to see
> how the freeze is coming when it’s out.

What packaging changes are you afraid of? The new triggers and the new -bin
package? What problems could they cause to reverse dependencies? Are there
packages calling gio-querymodules themselves?

> For GTK+ 2.22, things are in a similar state. Even larger packaging
> changes are being introduced because gdk-pixbuf was split in a separate
> module. However I’d prefer to see it in squeeze, otherwise backporting
> GTK+ 3.0 will be very hard. Of course I’m only proposing it since it
> doesn’t use GSettings. 
> 
> For GTK+ 3.0, the plan is to rely on backports since we don’t even have
> a release date.

I've heard about the release being on Christmas, but that's probably not set in
stone yet.

> If we ever happen to see it available during early
> freeze time, we can try to squeeze it in. But in any case, direct or
> indirect dependencies of meta-gnome2 must not depend on it. It would be
> just so that GTK+ 3 applications can be built on squeeze without
> backports.
> 
> Do you think this is realistic?

I'd say it depends on when the RT plans to freeze the archive. If soon (e.g.
this month) maybe we should just release with 2.30? But if they don't plan to
release anytime soon, updating GLib and GTK+ doesn't bad to me, although I don't
see much benefits in updating GLib.

Cheers,
Emilio


Reply to: