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

List:       kde-release-team
Subject:    Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
From:       Alexander Neundorf <neundorf () kde ! org>
Date:       2014-04-30 19:52:58
Message-ID: 5724746.p3qAKxWC3k () tuxedo ! neundorf ! net
[Download RAW message or body]

On Wednesday, April 30, 2014 15:51:56 =C0lex Fiestas wrote:
> On Wednesday 30 April 2014 13:44:50 Raymond Wooninck wrote:
> > > So, you will not simply update to 4.14.X but instead do cherry-picking
> > > of
> > > the bug fixes? Because that would be the same with Frameworks.
> > =

> > You got that one wrong :)  We push the 4.14.x release as a full
> > maintenance
> > update. So if 13.2 is shipped with 4.14.0, then 4.14.1 is pushed as
> > maintenance update as soon as it becomes available.  This is no longer
> > possible with Frameworks.
> =

> It is, you (as in opensuse) just have to get over the drama of having sma=
ll
> features in on each release.
> =

> Let's try to analyze a bit why some distros have this panic to new versio=
ns
> containing features (when it comes to KDE).
> =

> For the longest amount of time in KDE4 has been releasing as a whole doin=
g a
> big release every 6 months. This had the following impact of how things
> were developed:
> -People would develop super big features, some times even new apps.
> -People would push last minutes features to avoid the freeze (if you don't
> get in then you had to wait up to 8 months for next release).
> -People would merge things that are not ready because if something is wro=
ng
> a bit was not a big deal (you had months to amend it).
> -Each release contained a lot of code changed.

Just my POV as a developer: I disagree strongly.
Having a stable branch where everybody (users, distributors, developers) ca=
n =

be sure only safe bugfixes went in, is a good thing.
It can make quite sure regressions are avoided. This is the big thing: a bu=
g =

fix (patch) release should at all costs not introduce regressions.
For a bug-fix branch, sometimes a hack is acceptable if it safely in some w=
ay =

avoids the bug, and makes sure it doesn't introduce regressions.
The proper fix for a bug may be more involved, and may have some risk of =

introducing unexpected regressions.

So, IMO, this is not "drama of having small features". This is the serious =

wish to avoid being yelled at by users if anything broke in a bug fix relea=
se.

Alex

_______________________________________________
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]