release schedule BoF

Albert Astals Cid:
idea is to shorten release
we have now lots of freezes and a branch
alex wants something shorter, suggested 3 months between release with only 1 month of freezes
put all freezes together on same date, release beta 1, in two weeks RC 1, in 2 weeks more release
Frank from Dolphin says cool
Lauren from KMail says no, too hard to use feature branches synchronise kdepim-libs -runtime
marketing harder
aurelien said +1
scottK said prefer if we first made sure master could be always stable before trying shorter release cycle
rekonq man said would like to improve feature plan cos it sucks (only used to get an extention to freeze)
vishesh said it sucks and he'd just move to KF5 if it happened
sune agreed with scott that flow should be implemented before release changes
aaron wrote lots, no time to read, he kind of agreed with new things like separating marking from release
sune said not enough quality so need .4 and .5
alex said some could distros care about maintaining old branch
ingwa said no proof shorten release cycle will achieve it. we could do it so then we get proof
we don't have an agreement, some say no some say yes, how do we move forward?
alex fiestas:
quite cumbersome to do freezes
idea is master is always ready, where you merge branches

like the overall direction for shorter releases, worried about how we get there
thinks we should try shorter by two weeks, then fix issues then make gradually shorter
would drop three month proposal and have a strategy to make it shorter
we can get rid of a few freezes immediately
soft feature freeze is stupid
soft translation freeze makes no sense
if we shorten gradually every time all the critics will cry each time
in our company we shortened from 4 weeks to 2 weeks, worked ok

we don't have the structures in place for short releases
we force them to focus on stabalisation by freezes, if we give that up then people will start to develop new features, if that works we are more flexible, it is really a shift

add tag for notification of new dependencies

can someone please kick kdelibs people to fix the tests
kevin: subscribe the list to test failures
translators ok with 1 month freeze

suggestion to collapse all freezes
suggest get only 1 freeze, shorten by 1 month, fix tooling so every new dep goes in log etc
only way to make this sensible is to enforce a commit policy

we want two things 1) collapsing freezes 2) fixing tooling
will make two proposals, 1 a bit shorter, 2 same with less freezes 6 to 5 months

5 months is random, 4 months fit into a year
would prefer 6 monthly release because that fits in to ubuntu


Re: release schedule BoF

By David Faure at 07/23/2013 - 08:22

<a href="" title=""></a> is very green.

Re: release schedule BoF

By Vadim Zhukov at 07/23/2013 - 09:48

2013/7/23 David Faure < ... at kde dot org>:
Altough this gets a bit offtopic... Here is the exempt from my TODO
list (I had not enough time to investigate all tests yet). Running on

The following tests FAILED:
6 - kdecore-karchivetest (Failed) # buggy test
(at minimum group ID inheritance specifics)
7 - kdecore-kdirwatch_unittest (Failed) # looks like
buggy test (uses QFSWatch?!)
11 - kdecore-kstandarddirstest (Failed) # probably a
buggy test (symlink already resolved after resourceDirs() call)
22 - kdecore-ktimezonestest (Failed) # buggy test
38 - kdecore-kservicetest (Failed) # XXX needs
konsole and baseapps
45 - kdecore-ktcpsockettest (Failed) # buggy test
46 - kdecore-ksycocathreadtest (Failed) # XXX needs Kate
51 - kdecore-kmimetype_nomimetypes (Failed) # buggy test
55 - kdecore-klocalsocketservertest (Failed) # OpenBSD does
not support abstract UNIX sockets
105 - kptyprocesstest (Failed) # buggy test
(execute should not be used for KPtyProcess)

That's not all the failed tests - there are 60+ more, that's just
tests I as able investigate till now. I want to finish that work, make
patches where applicable and put 'em on reviewboard. But I think you
should know.

You see, from the 10 failing tests investigated:
1 test (correctly) fail because underlying OS does not support the feature.
2 tests require some stuff that itself depends on kdelibs - not a big
deal, but it's definitely not The Good Thing.
7 other tests are just buggy.

Just my two tes^H^H^Hcents.

kdelibs unittests

By David Faure at 07/23/2013 - 10:07

On Tuesday 23 July 2013 17:48:25 Vadim Zhukov wrote:
In case you're not doing that yet: you need to install kdelibs and kde-runtime

The dependencies on stuff from outside kdelibs have been reduced in the
frameworks branch, feel free to pick fixes from there if they help in the
stable branch. (e.g. the dependency on konsole and kate are removed iirc)

Alternatively, build the frameworks branch and run the tests as indicated on
<a href="" title=""></a>
These are more standalone already, although I'm sure you'll find more issues,
which I'm interested in.

Sounds good.


Re: release schedule BoF

By Albert Astals Cid at 07/23/2013 - 09:00

Lost in translation, i said kdepim instead of kdelibs.


<a href="" title=""></a> is very green.

Re: release schedule BoF

By Jaime Torres Amate at 07/17/2013 - 06:03

Why not the other direction?
4 months to develop new features, 2 months freeze and fixing?

Jonathan Riddell < ... at jriddell dot org> escribió:

Re: release schedule BoF

By Albert Astals Cid at 07/17/2013 - 19:21

El Dimecres, 17 de juliol de 2013, a les 12:03:53, Jaime Torres Amate va
Because this doesn't move in the direction most of the people agreed we want
(shorter releases, more candence).