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

[Christian Mollekopf]

On Friday 11 April 2014 14.50:25 laurent Montel wrote:
> 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.
> 

Agreed ;-) I will be fairly occupied with non-frameworks work.

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

Rewriting the message list would certainly be intrusive, so that's a good 
example I guess ;-) A new application wouldn't be a problem because it's  a 
separate codebase and everyone is free to no use it. I just mean something 
that touches a lot of existing code (making merges more difficult), or changes 
fundamental parts of the infrastructure affecting the stability of our main 
applications.

I think we will even sometime need to make intrusive changes in order to fix 
stuff like the calendar memory usage or alike, but it would help a lot if we 
communicated what we're planning to do, so we have a bit of a roadmap where 
we're going. Because right now the only way to see what's going on is to watch 
the commits, at which point it's usually already too late to change anything.

> > 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 :)
> 

Fair enough, if we can agree the development on master goes towards 
stabilizing kdepim, and we can agree to create somewhat of a roadmap for that, 
then that's all I was hoping for =)

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

That's fine with me. I will create a roadmap page for kdepim where I will put 
the things I plan to work on, and I would be grateful if you could add the 
stuff you plan to be working on there, or even just drop a mail to the ML so I 
can add it.

Thanks,
Christian

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

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