Future frameworks releases

[Christian Mollekopf]

On Tue, Jun 9, 2015, at 10:32 PM, Kevin Ottens wrote:
> Hello,
> 

Hey Kevin,

Sorry for the late response.

> On Tuesday 09 June 2015 10:08:06 Christian Mollekopf wrote:
> > On Monday 08 June 2015 18:47:06 Kevin Ottens wrote:
> > > Is it me or this whole thing is making most people life harder to please
> > > one person? I'm getting this feeling based on the past discussions on
> > > k-f-d and the replies here.
> > 
> > Your not pleasing a person, your considering a usecase.
> 
> A use case trumped by... one person (AFAIC). Really when I look at the
> thread here and the thread on k-f-d I only see you pushing hard for it and
> almost everyone else moaning.
> 

True, I just wanted to make clear that this is not only about making me
happy,
and I tried to lay out clearly why there are technical reasons why a
library should
be versioned individually.
While I personally believe versioning the libraries individually is the
right thing,
I could see why I'm the only one pushing in that direction because I'm
the only one
(in this discussion), that also has a professional responsibility in
that regard and a
special usecase because we're using those libraries also on servers.
So not your typical desktop usecase.

(I may be completely wrong about that and others have similar usecases,
but I'm
not aware of them)

> > I am in a special position because I not only have to represent my personal
> > opinion (which is that proper versioning does more good than harm), but I
> > also have to ensure that we can rely on the frameworks we use in an
> > enterprise environment in the long run, and part of that excercise is to
> > have them properly versioned.
> 
> And it's hard to not point that perhaps the reasoning leading you to
> "part of that exercise is to have them properly versioned" is tainted by your
> personal opinion. Note that I'm not blaming here, this kind of "after the facts" 
> rationalization is human and utterly common.
> 

Yes, this is my personal conclusion and what I concluded in discussion
with others.
Certainly not the universal truth.

> > I'm sorry for the friction this causes right now, but in the long run I
> > really don't see how this makes life harder for everyone else.
> 
> I think it's been pointed several times that it'll be generating work for 
> others to various degrees.
> 

Some scripting effort apparently (but not a whole from what I heard),
and some references 
to "dependency hell" is all I got back.
The scripting effort seemed surmountable, the "dependency hell" argument
is IMO
not applicable (if we take the definition from wikipedia).
We're not depending on specific versions and that works for the 
remaining libraries in the unix world as well.

> David doesn't like it but found a way to mitigate the effects for him.

Yes, and I appreciate highly how he was willing to entertain a solution,
even though he was against it in the first place.

> I think that all the packagers I've seen on this thread don't like it either
> (with various level of dislikes), some might live with it still and workaround
> it. Honestly, I don't see a great deal of support for that idea.
> 

True.

> Beside, I hope it's not only me but I tend to expect people to show some 
> respect for the space they enter.
> When joining someone to live under his roof for a while, I respect the
> customs of the people living there and make such customs my own, I don't rush to
> the kitchen to reorganize it to my liking/interest[*].
> 

Well, I really hoped to convince come people in that discussion, or to
get my own opinion
adjusted by technical reasons I didn't foresee. Neither happened which
made this whole
discussion a rather frustrating exercise.

I know I pushed this hard, and I did so because I think it's an
important topic, and because
I think it's for the best of frameworks, and not only me. But I have no
intent of being disrespectful,
so if that's what came across then I'm sorry.

> > > It's still time to reconsider I guess.
> > > 
> > > Note that I think that kdepimlibs should be mostly swallowed by KDE
> > > Frameworks. As much as I'd love to see it happen, I'm becoming less and
> > > less sure it can be to the expense of making weird exceptions like what's
> > > proposed.
> > 
> > If the Frameworks would be versioned (as opposed to timestamped) we wouldn't
> > have to make weird exceptions in the first place.
> 
> Well, yes, of course, "if you follow my demands, then we wouldn't have to
> make an exception"...
> 

I meant to say that I think it would be a more reasonable default to
have all libraries
versioned independently, and simply bump the ones automatically that
don't want this (which still may be the majority),
for lack of manpower/maintainer reasons. But I was clearly a bit
frustrated at that point, sorry.

> [*] Note I'm not saying such customs are then frozen. Since a new person 
> joined, which will create new interations, after a while the customs will 
> change gradually. The kitchen might even get reorganized in the end but
> for sure in a very different way than if I rushed in with my own preconceived 
> ideas.[**]

I'm glad to hear that. Until then I guess my options are limited:
* I can keep kimap out of frameworks, but that doesn't buy me a whole
lot as I still rely on other frameworks,
and most of the PIM libraries really ought to be frameworks. So I'm not
inclined to do that.
* I can maintain versioned branches for all frameworks I need, which is
going to be a PITA, but at least for me only.
This is likely what's going to happen until we can adjust the versioning
policy somehow from by POV.

Cheers,
Christian