KIMAP2

[Christian Mollekopf]

On Tue, Nov 15, 2016, at 05:44 PM, laurent Montel wrote:
> 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 :)
> 

My code is publicly available so you can perfectly well review it if you
like.
But as Kevin pointed out, I'm not proposing KIMAP2 as a KDE Framework.

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

Agreed.

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

I did not intend to come accross as if everything is set in stone and
you now have to adapt, I'm sorry if it seemed like that.
I tried to line out my plans so we can discuss how to best move forward.

> If you want that we use or put in master you need to help us to port to
> kimap2 or make the porting.
> 

If you want to port I can certainly help at least with instructions.
I so far did not know whether that is the intention or not.

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

Ok. From that I understand that you're ok with KIMAP2 entering master
once we're getting to a release of KIMAP2?
And we'll need to figure out if you want to keep KIMAP(1) in frameworks
or not.

Cheers,
Christian