KIMAP2

[laurent Montel]

Le mardi 15 novembre 2016, 16:30:17 CET Christian Mollekopf a écrit :
> On Tue, Nov 15, 2016, at 03:55 PM, laurent Montel wrote:
> > Le mardi 15 novembre 2016, 15:13:09 CET Christian Mollekopf a écrit :
> > > Hi,
> > 
> > Hi,
> > 
> > > I have largely completed the transition to KIMAP2 and will thus retire
> > > KIMAP. Since I know you are probably continuing to use KIMAP at least
> > > for some time, I made KIMAP2 completely coinstallable and namespaced
> > > everything into KIMAP2.
> > > However I will only be able to maintain KIMAP2, and not KIMAP. If you
> > > want to keep KIMAP around (I assume you do), I suggest we release it
> > > from a stable branch "kimap", as I would like to move master to kimap2.
> > > If that causes large problems with the way things are released let's
> > > discuss alternative solutions.
> > 
> > I understand that you don't  want to maintain KIMAP (but you are the
> > maintainer...)
> 
> Right, and as the maintainer I have made the changes I deem necessary to
> kimap resulting in kimap2.
> The only reason I have namespaced kimap2 and made it completely
> coinstallable is because I acknowledge
> that we have different ideas on how libraries should evolve (with
> frameworks and all), and I have no interest in working against anyone,
> so I'm trying to build solutions instead.
> 
> > but we can't merge KIMAP2 as it. It was not reviewed, we
> > didn't see a usage of it (just kube which is not release yet).
> 
> I'm very open for feedback but there is no requirement for me to have
> all my code reviewed (It's certainly good practice,
> but this doesn't make KIMAP2 unreleasable).

I don't see how you can ask to put as framework if nobody can review easily 
your code :)

> > Kdepim uses it for kdepim resource, it's used from age, it's stable.
> 
> Right, and the last team we discussed I got the impression that you (and
> others) want kimap in frameworks and keep using it from there for
> kdepim.
> Which is why I made it coinstallable.

Kimap from framework yep but kimap1. Not a new lib which is not use by any 
released apps...

> 
> > Nobody evaluated your new code, as you commited them without review
> > between patchs.
> > 
> > So for sure we will not merge in kimap now.
> 
> Well, I'll release kimap2 sooner or later in one way or another.
> I'm not trying to make things difficult for anyone, so this is more
> about finding the best way that works for everyone.
> 
> > But it can be live in dev/kimap2 if you want but not merge directly in
> > kimap.
> > 
> > Or you can create a branch "kimap2" or a new repo if you want to release
> > it in the future, but merging in kimap at the actual state is not
> > possible.
> > 
> > There is no reason to merge it in kimap directory, so you don't have date
> > for release imap, it's not stable and it was not reviewed.
> > 
> > I don't want to have in master a not used lib which is not stable and
> > perhaps stable in very long term.
> > 
> > If you want to create a framework you need to maintain it... (not as you
> > did with kimap...) => you need to fix bug report reported on bugzilla etc.
> 
> If we didn't have different ideas how this works we wouldn't have KIMAP2
> either (it would be simply KIMAP with a major version bump).
> 
> KIMAP2 is going to be an independent library that you can use or not
> (this is really up to you),

You arrive with a new lib without explaination how to port it and you told "ok 
now it's kimap2 in master" no it's not the method.
If you want that we use or put in master you need to help us to port to kimap2 
or make the porting.


> and I suggest, if you want to keep KIMAP
> around, to release it from a stable branch (that you can call however
> you like).
> KIMAP is not getting any new developments, so I don't think master is
> the right place for it in the long run.

But kimap is use and release for kdepim.
If we change branch we will increase complexity for distribution for a lib 
which is not used.

So a branch as KIMAP2 is good as we did when we migrate to kf5
=> master is kimap1 and branch kimap2 is a potential future.

But it will not create problem with distribution.


> As I said, if this is causing unresolvable problems  or we need a
> transitional solution I'm open for suggestions,
> but dev/kimap2 is not going to be the place where we'll work on it in
> the long run.
> 
> Cheers,
> Christian


-- 
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, 
 www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent 
software solutions