KIMAP2

[Christian Mollekopf]

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

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

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