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

Fri Apr 11 15:06:55 BST 2014

On vendredi 11 avril 2014 15:16:11 Christian Mollekopf wrote:
> 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.

Ok it’s not in my mind to rewrite all :)

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

Ok

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

I already did it 
See http://techbase.kde.org/Schedules/KDE4/4.13_Feature_Plan
So we already have a page for it.

But if you want to add new page not a problem for me
I will add info in these page.

Regards

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

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/