[Kde-pim] Focus on stability, LTS branch, transition to frameworks

Mark Gaiser markg85 at gmail.com
Fri Apr 11 21:18:46 BST 2014


On Fri, Apr 11, 2014 at 11:16 AM, Christian Mollekopf
<mollekopf at kolabsys.com> wrote:
> Hey,
>
> With the release of 4.13 and work already having started on frameworks (also
> on the pim side), I think it would be great if we move the general development
> focus to frameworks and only stabilize current kdepim.
>
> One way to go about this would be to define current master as an LTS branch,
> where we try to keep new features, refactorings and similar large scale
> changes away and focus on performance and stability improvements.
> If we can agree on that I'd like to do a bit of roadmap planning for this
> branch, so we don't get arbitrary changes and can perhaps discuss beforehand
> how this is going to work. If developers want to work on new fancy stuff, then
> they can in the branches that are going towards frameworks.
>
> This way we can now make sure we get a kdepim version that becomes rock solid,
> and isn't destabilized anymore, while all resources available can focus on
> getting the next generation (framworks) ready.
>
> Obviously I have a special interest in having a bit of control (as in
> overview, not enforcing control) what's going on in this LTS version, as I'll
> be doing a lot of stabilizing and performance improving (and perhaps one or
> the other necessary feature here and there), over the next half year or so,
> and I'd like a clearly defined way that I can keep the stable branches as close
> as possible to upstream and that allows me to primarily work on upstream
> backporting stuff to my stable branches, and not the other way around. I think
> this would be in the best interest of everyone involved =)
>
> So, I'm suggesting the following branches:
> * frameworks: Preparation for the split of the repositories
> * master: LTS, development focuses on stability and performance, we do a bit
> of roadmap planning for it and communicate over the ML (or a wiki) if we plan
> to do something larger.
> * KDE/4.13: patch releases as usual
>
> 4.13 would  be merged into master as usual, and master would be merged into
> frameworks.
>
> If you think it's too confusing frameworks should better become master, and
> then we just use a KDE/LTS branch, that's fine for me too.
>
> Thoughts, comments, objections?

-- Copied the question from the "kolab stable branches" thread --

something I've been wondering but never asked. Why don't you just
declare kontact 4.13 done, feature frozen and put it in bug fix only
mode? Then create a new branch for version 5.0 (kontact 5.0) on kde's
git infrastructure and work on top of that?

It's not like a lot of people are working on kontact anyway. Just
looking at the git log (kdepim repository), it's tons of small bug
fixes by Montel Laurent and a bit of Sergio Martins commits mixed in
between. But it doesn't seem like anything major is going on in there.

But what you are planning - feature wise - is going to be quite a
change anyway so upping the major version should be justified, right?

-- addition --
Version 5.0 might incline a Qt5 based kontact while it would still be
Qt 4.8.x based in the KDE 4.xx series. That will be confusing people.
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list