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

[laurent Montel]

Hi,

If I remember we will have a kde 4.14, so I don’t want to freeze master until 
we release a KF5 version which will be release in 1 year or 1 year 1/2

If we don’t make a 4.14 ok but until now we will have a 4.14

And as you told you will work on your own git and backport fix in your branch 
so it will not a big problem for you.


So work on framework is a good idea (I started to do it), but stop development 
in 4.x is not, I don’t want, and I don’t want to develop a feature and wait 1 
year to release it.

When I see kde-workspace which is release as 4.11.x and no changes during some 
months/years, I don’t want it for kdepim.

I want a real 4.14 release.



Regards.


On vendredi 11 avril 2014 11:16:30 Christian Mollekopf 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?
> 
> 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/

Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53,  http://www.kdab.fr

-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53,  http://www.kdab.fr


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