Releases in 3 months

[Philip Muskovac]

On Monday 08 July 2013 15:04:40 Àlex Fiestas wrote:
> Now that kde-workspace and kdelibs are going to be frozen (which in theory
> means less work for everybody) I'd like to propose a new release schedule to
> be applied starting with 4.12.
> 
> Basically the idea is to cut testing time and compensate it by keeping
> master always in a "releaseable" state, now that two major components are
> frozen it looks like it is a good time to get used to it.
> 
> You can read all the proposal in:
> http://community.kde.org/KDE_Core/ReleasesProposal
> 
> Before sending this email I have checked with distro people, i18n people,
> other developers and almost all of them seemed to either like or be neutral
> about it (only one exception :p) so I hope that the proposal is not a
> complete disaster.
> 
> As its name indicates, it is a proposal, so please be constructive in the
> feedback, we can change as many things as we need.
> 
> Finally, I have scheduled a Bof at Akademy, would be nice to have all the
> feedback from the community that is not able to come before it happens:
> 
> http://community.kde.org/Akademy/2013/Wednesday#Room_A2_-_17_July
> 
> Cheers !

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)

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.

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.

Cheers,
Philip