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

laurent Montel montel at kde.org
Fri Apr 11 13:50:25 BST 2014


On vendredi 11 avril 2014 14:00:22 Christian Mollekopf wrote:
> On Friday 11 April 2014 13.11:11 laurent Montel wrote:
> > Hi,
> 
> Hey Laurent,
> 
> > 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.
> 
> I generally think it makes sense for a community with very limited manpower
> to focus on one or the other thing, and IMO the best thing to do would be
> to not put too much effort into 4.14 but rather make sure frameworks is
> ready as soon as possible.

The problem is as you told "community with very limited manpower" I can say 
that there is some active developer: You, Dan, me and sometimes so developer 
which create patch etc. (Ok during 2 days in sprint there is more dev).

I know too that port to a new version is a very hard work (I participated to 
2.0-> 3.0 and 3.0 -> 4.0).
So I know that we focus all your time to work on framework we will not able to 
release quickly (1 year minimum).

And I don’t think that you will have time to focus to framework for next 
month.

> However, I don't want to freeze master, but I think it would be highly
> beneficial to do some roadmap planning for 4.14 and perhaps to postpone one
> or the other intrusive feature to frameworks. That means we still can add
> new features and release them with 4.14, if we think it's worth the effort,
> but we maybe do so in a bit more transparent way.

What do you mean by "intrusive feature" ?
- Create a new application ?
- Rewrite messagelist ? (I will not do it :) )
- Add new feature to kmail ?


> This allows developers to focus on frameworks, while the parties interested
> can stabilize Kontact. Running full steam on two branches (master and
> frameworks), will IMO just make everyone's work harder, and further
> distribute the already scarce resources.

Yes if you have enough developers :)

> What I would like to reach with 4.14 is a Kontact release where the features
> we offer finally work (at least in most cases), and I think it would be
> great to reach this before making the next big changes. If we can agree on
> this goal for non frameworks Kontact I'm sure we can find a compromise that
> works for everyone.

I am agree to stabilize kdepim* in 4.14 it’s not a problem but I don’t want 
stop to create a new feature in 4.14 just because we will (a day) release a 
kdepim framework.

I remember during akonadi porting which started in 4.4 we wanted to release it 
in 4.5 and finally we release in 4.7 => 1 year after. And we keep a kdepim 4.4 
without changes with same features during 1 year 1/2 because we wanted to 
release akonadi version and focus all your work on it.


Regards.

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


More information about the kde-pim mailing list