Releases in 3 months

Àlex Fiestas afiestas at kde.org
Mon Jul 8 17:09:44 BST 2013


On Monday 08 July 2013 17:45:10 Philip Muskovac wrote:
> Hi,
> 
> With my Kubuntu Developer Hat on, one concern I have is the support
> timeframe for the planned 4.13 release. Kubuntu 14.04, planned to be
> released in April 2014 will be a Long Term Support release meaning we'll
> have to care about it for quite a while. (And it might very well be our
> last release based on KDE4/Qt4/X11 depending on how things go in the next
> 1.5 years)
> 
> I understand that we can have additional point releases if people still find
> issues that need to be fixed, but with so many short release cycles I
> expect that the attention for the previous release (even worse: the one
> before that) will die quickly leaving the distributions with having to do
> the bugfix backporting.
> That's ofc. already the case for older releases, but shorter release cycles
> only amplify the issue as no distribution will change their release cycle to
> match the new KDE one. (leaving rolling distros aside)

Yes, my idea is to have interested parties to maintain whatever branch they 
are interested on, for example I know that Redhat is still maintaining 3.5.10 
branch, which I think it is awesome but we have moved on.

We can develop tools to make your life easier (distros) so you can maintain 
yourselves branches for things like LTS easier, I will be willing to develop 
such tools if needed.

> As Scott pointed out, it will also lead to less distributions shipping the
> same KDE SC release version which leads to less testing efforts for a
> specific release and more support workload for the distributions later.
Take into account that versions will be smaller, meaning less change, less 
work.

> What would at least make my life easier here would be a way to easily get a
> list of all patches that were applied to a stable release (esp. when someone
> bothers to backport a fix after the last point release is out).
> The only way to do that, that I found so far, is filtering out mails from
> kde- commits, which is neither very easy nor reliable.
If this is what it takes for having distros in, I propose myself to develop 
this system ! we can have a BoF in akademy perhaps to design such tool.

Cheers !




More information about the kde-core-devel mailing list