Re: Stable, long term support releases for gtk+

[Lanoxx <lanoxx gmx net>]

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
> futility.
>
> 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.
>
> ciao,
>   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
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list