On Wednesday 17 June 2015 23.01:41 Kevin Ottens wrote: > Hello, > Hey,
> On Tuesday 16 June 2015 11:14:28 Christian Mollekopf wrote: > > On Tue, Jun 9, 2015, at 10:32 PM, Kevin Ottens wrote: > > Sorry for the late response. > > No worries, it's not like I'm very responsive either. I didn't manage to > participate properly on the k-f-d discussion on that topic for a start. ;-) > > > > On Tuesday 09 June 2015 10:08:06 Christian Mollekopf wrote: > > > > On Monday 08 June 2015 18:47:06 Kevin Ottens wrote: > > > 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. > > Sure. I think some arguments were left behind though. I might be wrong, but > I think the "well, Qt does the same and it's apparently not a problem" > wasn't properly addressed. > Alright, something that I'll need to address then. > > 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 > > I don't think I agree there, you're not the only one with professional > constraint toward KF5. > > > in that regard and a special usecase because we're using those libraries > > also on servers. So not your typical desktop usecase. > > That OTOH, it's extremely likely that you're the only one indeed. > > > [...] > > 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. > > Sorry about that as I clearly added to the frustration. > > > 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. > > I don't think you've been disrespectful. I guess that was the limit of my > metaphor which carried this feeling... turns out my footnote was better in > that regard. You've been obstinate though, but clearly you've not been alone > with that trait. :-) > Alright, that's fine then. I think I have to be a bit obstinate in this situation, but I really don't want to piss people off, which is sometimes difficult to handle via email. > Right now, I think the problem is that we have two parties running in circle > not being able to convince each other and no mechanism in place to deal > with that. > Indeed. > > 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. > > BTW, I'd like to point out, because I think was not clear in that regard > earlier. That personally I don't mind if we decide single version vs > multiple versions. I see pros and cons in both. > > What I'd like though is that either we go in one direction (different > versions as the norm), or the other (status quo), but we don't go for "A, B > and C do that while X, Y, Z does something else". It's what I tried to > point with "weird exceptions" earlier and failed. > Ok, with that I can agree. I'm glad to hear you're opinion isn't set in stone on that topic, because that's what I (mistakenly) extracted from your previous responses. > > > [*] 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. > > As I said earlier I don't like that much either, I'm glad you're not > contemplating it despite the amount of sometimes extreme negativity. > > > * 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. > > If we don't manage to devise something consistent upfront I think that's a > path. With the "running in circles" I was mentioning earlier that might be > for the time being the practical path. > > I think that's the case because this way we'll see your work in those > branches and that might help document and understand the pains you're > mentioning and we can't seem to be able to understand at the moment. > > > Now, among all the noise in both threads, I'd be surprised if we don't have > a proper solution hiding somewhere, we likely have the pieces but not > properly put together. > Since I'm currently swamped with work I'll have to put this on the back-burner for the moment, and as suggested we can pick this up during akademy. Until then I can also do some more preparation to explain the specific requirements better, and with that we can hopefully devise a solution that works for everyone. Cheers, Christian > Bear with me I'll be partly acting from memory here... let's see something > like: > 1) KF5 releases are numbered YYYY.MM; > 2) Individual frameworks are numbered 5.N, N being incremented only if > there's been commits since the last KF5 release; > 3) Each KF5 release directory contains tarballs of all the frameworks in > their latest version. > > (1) and (2) would decouple completely the collection numbering from the > individual frameworks numbering and would open the door to what you ask as a > rule not an exception. That should allow different version numbers between > the frameworks while avoiding the confusion of a collection version 5.20 > containing frameworks in version 5.12. We avoid that proximity altogether, > since no one would be surprised of the collection 2016.02 containing a > framework in version 5.12 another one in version 5.15, etc. > > I guess (2) would need to be tuned to David's and your liking. So that N is > bumped for each framework in a way that please you both[*] (higher > priority), ideally in a way where it can be expressed as a uniform rule for > all frameworks. > > (3) should cater the need of users wanting to pick a working subset of > frameworks. The argument was "easy they all have the same number", it > becomes "easy they all are in the same directory". Not as powerful but good > enough I would say. > (3) should also cater the packagers needs or inqlude needs as it's basically > listing the folder[**]. If needed a manifest file as you discussed could be > generated in the folder too. > > Now I feel like it'll be arguing about (2)... but at least we get a chance > of being more focused. > > Regards. > > [*] Note that IMO, that tuning should not involve going toward 5.N.M version > scheme. The 5.N only scheme was intentional and debated quite a bit > already. It's intentional to have a combination of very short cycles and > feature + bugfix on each releases. Packagers were skeptic about it but it's > been proven to work now. > > [**] A problem I see with the idea of sometimes not putting a framework in a > release directory is that it makes it harder to do that properly or at > least more error prone. _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
