Fwd: KDE Frameworks Release Cycle
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the release-team