No more release schedules.
annemarie.mahfouf at free.fr
Tue Jun 14 13:37:22 CEST 2011
On Thursday 09 June 2011 19:28:13 Tom Albers wrote:
> 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 http://techbase.kde.org/Schedules/KDE4/4.7_Release_Schedule 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.
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?
More information about the release-team