[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Plasma Next Release Plans
From:       Sebastian =?ISO-8859-1?Q?K=FCgler?= <sebas () kde ! org>
Date:       2014-02-19 22:29:42
Message-ID: 2945552.UzS6XAnvls () monet
[Download RAW message or body]

On Wednesday, February 19, 2014 21:01:52 Martin Graesslin wrote:
> On Wednesday 19 February 2014 20:42:15 Albert Astals Cid wrote:
> > El Dimecres, 19 de febrer de 2014, a les 15:01:50, Sebastian K=FCgler va

> > > The Plasma team has settled on a release schedule for the first stable
> > > released based on Qt5 and KF5. You can find the schedule here:
> > > =

> > > http://techbase.kde.org/Schedules/Plasma/2014.6_Release_Schedule
> > =

> > I find interesting that you reintroduced the concept of soft vs hard
> > freeze.
> > =

> > Can you explain the rationale behind getting them back? Do you think the
> > single freeze we introduced in the latest 4.x is working worse than
> > soft+hard freeze?
> =

> I just checked our discussion (for reference mail by d_ed to plasma-devel=
 on
> January, 29th). His request was to have two feature freezes allowing to
> have certain aspects unfinished at freeze 1. So I'd say it's completely
> unrelated to the SC freezes as it's for the special situation of the
> current development state.

Yes, I think it's specific to this release cycle, as we have a wider gap fr=
om =

"port everything and possibly break stuff" to "stable software", so it make=
s =

sense to me to have a process with more steps in between.

What I've seen myself is that focus is shifting towards solving bugs and =

making things work, the two freezes give opportunity to ease into =

stabilization phase, while some things are still being completed.

I think once we've finished this bigger transition, we can get back into th=
e =

proven rhythm, and possibly tweak it. There were some discussions about =

shorter release cycles, this certainly warrants picking up again.

As to point releases, we haven't talked much about that, but experience =

teaches that especially after the big transition, we should be prepared to =

ship updates in short order. For that, I'd like to (at least?) keep the onc=
e-
a-month-a-point-release cycle. We should start scheduling this as well.

Cheers,
-- =

sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]