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

[Cédric Villemain]

Le vendredi 11 avril 2014 14:50:25 laurent Montel a écrit :
> 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.

From "userland", while it is nice to have new features, having a working  
tool is even more interesting.

There is something to balance between how to get more developers and not 
loosing users (else you have a tool used only by developers, which IMHO 
is a failure)

Just my 2 cents, I won't argue to do one way or the other, nor try to 
define a policy.
-- 
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140411/d7782890/attachment.sig>
-------------- next part --------------
_______________________________________________
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/