[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