Re: Stable, long term support releases for gtk+

On 04/01/13 14:08, Emmanuele Bassi wrote:
hi all;

a couple of points have been raised on IRC, so let me try to summarize
them here:

   • "LTS" is probably the wrong name, given that it has "support" into
it; I merely used a known name, but what this whole initiative is
about is to provide releases coming from upstream (the GTK+ project)
that can be used downstream (the GTK+ distributors) to avoid
distro-specific silos, or different bug fixes reaching downstream
distributors at different times;
   • related to the point above, the scope of this initiative is to
integrate (well-tested) patches, either coming from downstream, or
identified from upstream: no new features, no sweeping changes, no
refactorings, and more importantly *no* *regressions*; I am currently
drafting a list of guidelines for the process of integrating patches,
to avoid unnecessary confusion, and to allow somebody else to pick a
branch up in the future, in case this initiative is successful.

there are some discrepancies in the versions chosen by different
downstreams, at the moment; plus, GTK+ 3.4 has its own quirks that
have been resolved in GTK+ 3.6, as well as in the current 3.7 cycle. I
think the current situation is inevitable, at least for this cycle.
even if we selected the next stable version, 3.8, to be the one with
long term updates (which would put some pressure on the things that
still need to land with just a month or so before API freeze), it
wouldn't do anybody good at least until the next LTS cycle in a couple
of years, and this whole thing would be a pointless exercise in

given the installed base that depends on GTK+ 3.4 and GLib 2.32
*already*, the sanest option is to do a run with those, and see how
this whole thing works out. for the next long term support cycle of
our various downstreams we'll probably be able to select a version
beforehand, and get everybody on the same page from the start.

  Emmanuele (who is not subscribed to distributor-list, so would
appreciate to keep gtk-devel-list in the loop when replying).

How about a better synchronization with downstream distributions during development of GTK+. If GTK+ would "sync" their long term updated version with Debian, Ubuntu LTS and other distributions that have a rather long development cycle, then it could be possible to prevent quirks in those releases that align with the long term version of those distros. To give an example it would be possible to reject changes that would introduce big and possibly unfinished features and delay them to the next cycle which then falls into a period of short term releases and can be better tested by early adopters, before these features are merged into the main branch.

For example in 3.12 (which will colide with the next Ubuntu LTS) the requirements for new features could be made higher than during other releases which do not happend together with a LTS version. The question would of course be if a version can be identified that fits for more than one distribution (e.g. Ubuntu and Debian and Red Hat).

gtk-devel-list mailing list
gtk-devel-list gnome org

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