Fwd: KDE Frameworks Release Cycle

Martin Gräßlin mgraesslin at kde.org
Wed Apr 30 13:19:34 UTC 2014


On Wednesday 30 April 2014 15:08:55 Raymond Wooninck wrote:
> On Wednesday 30 April 2014 14:39:31 Martin Gräßlin wrote:
> > I know that this is a change from how it is right now: but wouldn't it be
> > better if those who are interested do these branches? Let's face it
> > whatever we do upstream cannot suite all of our downstreams at the same
> > time.
> If I take your words literally here, then upstream is not interested in how
> the distros is packaging KDE. The only point of interest of upstream is to
> deliver  new releases.  This is kind of dumping everything to the distros
> and let them sort things out.  I really wonder if this is the release
> methodology that Frameworks want to apply ?

I fail to see how you could have read this into my mail especially considering 
the other mails where I explained that the new approach is a measure to 
increase the quality.

> 
> > And please remember: this is only about frameworks, not about the
> > applications or the workspace.
> 
> But the proposed release cycle for Frameworks could set an example for the
> others.  If this is the way frameworks will follow, what would stop the
> others from doing exactly the same.

Nothing. In the same way nothing would stop them to do that without frameworks 
doing that. I already shared my plans for a rapid release cycle for KWin 
during the Wayland port with fellow developers months ago before this 
discussion for frameworks started. At the same time we decided that for Plasma 
as the desktop shell it's not suited. Different projects need different 
release cycles and I'm quite sure that every application will pick the 
approach which is suited best for them and the stakeholders.

We live in a git world and rapid release cycles help to increase the quality. 
Following this thread I sometimes think people still think in svn. It's quite 
simple: master is always stable. Period. Code which doesn't have the quality 
cannot get merged in. Code that doesn't have test coverage cannot get in. We 
are not switching to a model where everything is lost and distros will have a 
hard time because the quality sucks and they need to fetch patches from 
everywhere. We are moving to a model where it should not happen that there are 
bugfixes needed (yes of course bugs will always happen, but if we fail to get 
at a point where it doesn't matter for distros, the approach will be wrong).

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20140430/e8e21c03/attachment-0001.sig>


More information about the release-team mailing list