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

Christian Mollekopf mollekopf at kolabsys.com
Fri Apr 11 10:16:30 BST 2014


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?

Cheers,
Christian
_______________________________________________
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