No more release schedules.

Tom Albers toma at
Thu Jun 9 22:27:20 CEST 2011

----- Original Message -----
> Seriously, though, you can still publish a KDE *SC* 4.8 (or 5.0 or
> whatever)
> and a corresponding release schedule called exactly that.

I think it is even more confusing to release kde sc 4.8 with for example, platform 5, pim 4.7 and plasma 2. What exactly does 4.8 stand for in that case?

> This is absolutely true. Creating distro packages from such a version
> mix will
> become a nightmare. Not to speak of the problem that there will not
> be a
> common "KDE SC experience" across all distros anymore but a pretty
> much random
> collection of modules according to the individual release plans of
> both
> modules and distros. (Not to speak of us source-based distros with
> "rolling
> releases".)

I doubt the release schedule can keep that together. If the platform releases version 5, distro's need to package it and then ship 4 too and some kde modules will be compatible with platform 5 and some won't ever. So, however we turn it, I see we can add some structure, but I do think that structure needs to be set on a per module base, no longer on a central base.

> Even today, some distros have either not even started working on the
> 4.7 beta
> because of the comparedly small mess we're already facing today. My
> guess is
> that those alphas (at different milestones) won't get much testing at
> all
> because we, as packagers, will likely have a hard time puzzling all
> the pieces
> together properly - and some of us most likely won't even bother to
> try.

Sure, and we can see a 'deadlock' in this mailinglist with that subject. Some packagers are ok with splitting, some want it consistent and some want it monolotic. I think the module maintainers should have a bigger role and responsibility here, as there can not be one guy on this list which decides all this.

I'm very concerned about the 4.7 release tbh, because I don't see a solution appearing while we need one asap. Maybe if we split it up and have responsible 'leaders' for each module we can prevent such situations and have a better uniform communication.

> So, if they don't like to work toward it, there won't be unified KDE
> SC
> releases anymore? And even if there are, there will be only *two*
> releases a
> year? I'd consider that a *major* step beackwards.

2 or also for all the minor release of just 12 release moments a year, that was not the point. That are details...

> > > Coordinate? We *create* releases and manage them.
> > We can still package and release them if you like, that's
> > independent of
> > the schedules.
> Uhm... No? *What* are you going to package? How are you going to make
> sure
> whatever you decide to package is actually going to work with the
> other
> modules? Of course, you can randomly pick some date, package and
> release
> whatever is available at that point but, from a QA point of view,
> this might
> not be the wisest approach to release engineering.

Well, it's up to the module maintainers to work out the release schedule to reach a stable release at the release point. I think that will work fine. We won't go randomly tarball some random folder. 

Thanks for the mail. It helps to clarify this idea better. 

Tom Albers
KDE Sysadmin

More information about the release-team mailing list