No more release schedules.

Anne-Marie Mahfouf annemarie.mahfouf at
Tue Jun 14 13:37:22 CEST 2011

On Thursday 09 June 2011 19:28:13 Tom Albers wrote:
> Hi,
> Since it seems some modules are going to have their own numbers and some
> modules will have a different (git) workflow, which will inevitably result
> in different release schedules, I propose we stop producing the central
> release schedule as we have now.
> So is the last
> one we provide. From here on, I think it would be best if the module
> maintainer or the particular git maintainer sets up a release schedule for
> their own module / repo. He can use the sofware in
> playground/utils/releaseschedule for their convenience.
I see 2 different things here: the release schedule and the release itself. The 
release schedule was put up by Tom (with agreement from the Release Team which 
I somehow do not really know what this is in reality) and the release process 
(making tarballs and sending them to packagers + including patches and sorting 
mess) is done by Dirk. A third task is the announcement itself made by Sebas 
and the promo team, the future being here that the promo team is more 

I am not sure how Tom's proposal would work in real world. For example I am 
the coordinator for KDE Edu (but not really the git maintainer which would be 
Jeremy maybe) and I don't see how I would manage to set up a release schedule 
in case of conflict.
If we all agree to follow the frameworks release schedule, we can set up the 
release page with your tool. But whose responsability will it be to make the 
tarballs? Same if KDE Edu agrees on a release date independently from the rest 
of KDE, does it mean we'll have to release and test the tarballs? and make the 

And what if the module apps want to have different release dates? To what 
extend is the power of the module coordinator?

> Of course this list can be used to coordinate a combined release between
> modules and what not.
> Even if this plan is vetoed away, I personally will not make a new
> schedule, as I have no idea how to do that in the new setup and I've
> little interest in studying the new setup.
still up-to-date?

Maybe we should put up a wiki page and list all modules and propose a 
schedule, see if they want to follow it. Some modules did not switch to git 
yet and should probably do it before 4.8. They need to make use of existing 
problems. For example I don't see why kdesdk would stay as a module, 
considering it's a collection of apps. Should it still be built in git as 
For packagers sake, can we then define KDE SC (= KDE apps = offical apps released 
apart from frameworks) as whole git building modules for 4.8?


> Best,

More information about the release-team mailing list