On Saturday, November 12, 2011 10:35:02 Kevin Kofler wrote: > Aaron J. Seigo wrote: > > first, let's back off from the unecessary rhetoric. for instance, i don't > > think calling people hypocrites is going to get anyone anywhere other than > > annoyed, upset and divided. i hope we can agree on that. > > Unfortunately, it's the decision by some kdelibs developers including you to > stop everyone from working on kdelibs 4.x which is annoying, upsetting and > dividing people. > > I don't want to offend you, but to make you realize this fact. > > I am sorry if I come off as rude, it's really not my intention, but you have > to realize that I'm really frustrated by this situation.
i understand you are frustrated. that is very clear :) i don't want you to be frustrated. at the same time, your frustration is not a reason to jeopardize kdelibs. my hope is that if we can communicate clearly why we are doing what we are doing and when we are doing it, that frustration will be avoided. we did a good amount of communication around this matter months ago. because of your frustration (and the confusion of others added to that), i've taken to redoubling efforts to get the planning better documented and yet another round of communication done. honestly, i don't (in theory) have the time for that. but it needs to be done because it matters, as you well know personally from this experience. but i, and the rest of us working on frameworks, remain committed to doing what is best for kdelibs as well as the broader community of KDE developers and users. we are not interested in short term thinking driven by frustrations over the immediate. > > On Friday, November 11, 2011 04:58:09 Kevin Kofler wrote: > >> You cannot really FORCE volunteers to work on what you want them to work > >> on. > > > > no, but we can decide to work together and coordinate instead of working > > against each other, particularly when we share the same final interests. > > Working together goes both ways, you also have to listen to our needs. we are. we're also listening the 10s of 1000s of other developers, KDE and Qt alike. we're also listening to the few dozen who contribute to kdelibs directly. the bulk of code written in kdelibs in the last couple of years was represented in Randa. (inc, btw, people working on Secret Service; which, if nothing else, shows that just because you are part of the discussions and getting support does not mean things will work perfectly; and that's ok: we can adapt and work on fixing things) > Nobody who doesn't read kde-core-devel daily and who didn't happen to be at > the in-person meeting you discussed this in was even aware of your post-4.7 > plans, let alone asked for their opinion. besides kde-core-devel, it was also blogged by a number of attendees, so planetkde.org readership was in the loop. there was a story on dot.kde.org, so dot.kde.org readership was in the loop. there's documentation on community.kde.org. hell, it even made it to slashdot (ok, that last one is NOT a good test ;) so we most certainly did communicate. you didn't catch it, and i agree that that sucks. but it is not because the communication didn't happen in all the most appropriate places. the only thing we could have done more for you is to track you down personally, and that's just not a realistic expectation. > In particular, nobody asked us > distro people for it: I don't recall any sort of notice about this issue to > kde-packager. seeing as we aren't disrupting the 6 month 4.x release cycle, it honestly did not occur to me to ask distros how we should schedule the next unstable version of KDE's libraries. i'm not sure how many other library developers ask distros about their future releases, either, though. (meaning: i think you're holding KDE to an unrealistically high standard here.) now, if we were simply stopping 4.x releases altogether, that would be a concern, yes. but we aren't. and we have been communicating broadly. i did reach out to packagers, btw, as can be seen in my blog entries and emails on the matter. and we did have at least one packager who attended Randa. however, it seems i didn't send email to the kde-packagers mailing list .. if that was a failing, i apologize. > Yet scheduling is definitely something which needs to be > discussed with distro packagers. even when we aren't stopping 4.x releases? not even delaying them? > this, it looks like Shuttleworth's lecture on how important predictable > periodic releases are for us distributions already got forgotten!) and that > IMHO it would have been better for everyone if it had been upstream by then. we're still doing 6 month releases of 4.x code. features are still allowed and encouraged in apps and workspaces. furthermore: to suggest that all features started now will be in a release within the next 6 months defies all experience: some features take longer. even Mark Shuttleworth has written blog entries lamenting the problems with sticking too tightly to 6 month dev cycles, and how sometimes you need some of the code to have periodic longer cycles. we're doing that for kdelibs in a very critical time ... all while continuing 4.x releases so users get new features in apps and workspaces, bug fixes in the libraries, and distros have new things to work with. > There is obviously no way we can ship a Plasma based on libplasma from > Frameworks in Fedora 17, so 4.8 was and is the target. And when I submitted i agree that this is a challenge when targetting development at one particular downstream's release cycle instead of upstream's release cycle. > my GSoC proposal, I didn't even THINK that there'd possibly be no kdelibs > 4.8, me neither. but somtimes things change. and your GSoC proposal was undestandably not the ultimate deciding factor in the schedule for frameworks. we knew there were tradeoffs. but they are tradeoffs with positive end ballances. > or one with no new features allowed. In fact I only heard of this > after my patches to PackageKit and Apper were all already finished and > applied upstream (which proved to be very straightforward, unlike libplasma > where I hit a brick wall). did you run up against PackageKit or Apper's devel cycles? had you tried to merge them during one of their feature freezes, or new features to a stable branch where new features were no longer being applied, do you think it would have been different? the "brick wall" you ran into is due to release coordination and planning. in that same time period, dozens and dozens of patches (some much bigger than yours) made it through review-board. take the recent libtaskmanager changes as one example. (libtaskmanager is in kde-workspaces, and not slated to be part of the frameworks 5.0) this isn't a problem with libplasma, it's a problem with you not being able to respect the devel cycle of the project you are contributing to. it happens. > > note that your statement is the same as saying that as a volunteer i can > > then commit anything i want to your application / library, which is, > > obviously, not true. there are means of process control, particularly > > maintainership. > > Sorry, but for me, keeping other people from doing their work is a sign of > bad maintainership. you aren't being held from "doing your work". you are invited to do it in frameworks. just as you are invited to do new work in master, rather than in the stable branches of modules. i understand you think that features should be able to land anytime in master.. and you know what -> i AGREE! frameworks, btw, is going to bring with it a new git-enabled workflow that allows features to be merged when ready into master at any time (without screwing over translators or stable releases; read the proposal if you have concerns about those things). to get there, which is where you want to be, requires we do not take some path-of-least-resistence choices the short-term. namely .. we focus on frameworks and freeze kdelibs 4.x for features. > I don't dispute that a maintainer is ALLOWED to do so, > but that doesn't make it a good idea. agreed ... > The fact that this topic comes up > again and again (see e.g. today's threads about ksecretsservice) proves that > several people have a concrete need for doing work on kdelibs 4.x. Instead, > they're forced to work around you (plural "you"!) when you could easily > allow them to work WITH you. (Again, working together goes both ways, > closing down the branch people want to commit to is NOT working WITH them.) aah, so when we do what you want, it's working with you. when you do want we want, it's working against you. :) c'mon ... look, putting features in KDE/4.7 means we, those of us pushing kdelibs to the next important major milestone, have to "work around" those feature efforts by increasingly heavy forward porting burdons and fewer eyes and fingers on the frameworks code. i've done some of this back-and-forth porting already and it is not easy (or fun :) and it really does slow things down considerably. i've spent large portions of a day handling just one set of merges, with no forward progress because of the merging effort. > > note that the decisions which i am simply repeating and asking people to > > respect were made this past summer in a meeting of some 30 libs > > contributors > > In-person meetings (a.k.a. the infamous "watercooler discussions") are about > the worst possible place to take decisions in a global community project > with many volunteer (and thus necessarily part-time) contributors. most of the people who attended Randa are volunteer (and necessarily part- time) contributors. those of us who get to spend "all" our time on these topics were the minority by far. it's also well documented at this point that getting those volunteers (and paid people, too) together face-to-face from time to time to work on this big issues pays off hugely. that's why we do so many developer sprints and spend so many of our financial resources on them. > > and then brought here to k-c-d for further discussion. > > That's a more appropriate forum, but why hasn't anybody notified e.g. > kde-packager? because we are continuing to do 4.x releases. as such, what does kde-packagers have to do with the stage at which frameworks is in? THAT said ... i did reach out to packagers for the Randa meeting and tried very hard to get packagers there. i was successful in doing so (e.g. Sune) but it was not easy. > And even then, there will always be people who missed the > discussion, which is another reason why reconsidering decisions based on new > evidence is sometimes needed. i am trying very hard to accomodate of your input here. i've gone through git logs due to issues you raise (see below for that...) we do need to stay reality based: sometimes new evidence turns out to not be concrete upon examination; other times it's evidence that has already been considered. sometimes, new evidence will indeed by new and concrete, but it takes more than just someone saying something for that to be the case. so .. let's dig... > I think the sample of developers included in your discussions suffered from > heavy selection bias, as (for various reasons) those people interested in > 4.x work aren't the ones who go to your long-term planning meetings nor the > ones who watch kde-core-devel daily. (I wasn't following it at all when this > was initially discussed.) 4.x work in apps and workspaces continues. those working focussed on libs issues and concerned about the future of kdelibs/runtime need to be following kde-core-devel. it's where cooridination happens. just as plasma coordination happens on plasma-devel. you don't need to follow k-c-d daily .. weekly is more than enough. in this case, monthly, even. > >> Preventing them from working on what THEY want to work on will just lead > > > >> to them moving their work elsewhere, e.g.: > > well, that's exactly what i hope will happen. i hope they will movetheir > > work into frameworks (either the branch if working on existing code or a > > git repository that will become part of frameworks) > > Putting the work into frameworks (only) is obviously not a solution for code > we want to ship now. i think we have a differing definitions of "we". i'm looking at the people who are working on kdelibs and representing their collective voice (including, btw, a few things that i don't/didn't personally agree with, but which i accept as the group's decision, and having a basis on other people's good reasoning ... ) > >> * separate git repositories (which in fact is exactly what you are doing > >> with libkactivities! > > > > yes, because that is the shape the frameworks will take: seperate > > repositories (easily fetched and built all at once, however, so no loss in > > "build it all" / "work on it all" efficiencies). the reason libkactivities > > is now in its own repository, along with its runtime requirements i might > > add, is to fall in line with what the frameworks plan is (not all of which > > i personally agreed to at first, btw .. life and big projects are full of > > being able to work with others, including at times agreeing with the group > > of skilled, intelligent people who have the same interests and goals as > > you do) > > Yet your libkactivities repository targets (also) 4.x, and you're sneaking > it in as a dependency of kde-workspace 4.8, as a result bypassing the "no > new kdelibs features for 4.8" policy on a technicality, and leaving us > packagers to deal with the resulting chaos (2 versions of libkactivities for > 4.x). first, there is no sneaking involved. second, that chaos would have existed _anyways_ since it was in kdelibs/experimental where the API and ABI is allowed to change. so: a) kactivities is a separate and new library (having been in kdelibs/experimental up till now) b) libkactivities was not being used by kde-workspace. a copy (!) of the code in libkworkspace was being used. c) since kdelibs 4.x is feature frozen, we went for the frameworks approach. because of the decoupling of libs devel cycles from apps and workspace, this allows us to very nicely use this library. other new libraries can easily enter the scene the same way. feature adds to existing 4.x libraries are obviously a different story. > Yes, I realize that you need the new stuff for Plasma Active. But why is and Plasma Desktop, the half dozen or so components in kde-workspace that use those classes and share-like-connect. > Plasma Active considered so important that the features it wants can get > into 4.x, you're confusing kdelibs with workspaces and apps. there are no new features being put into the kdelibs or kderuntime modules due to Plasma Active. in fact, we caried some rather large patches so that Plasma Active specifically did NOT interfere with release cycles (we butted, for instance, right into the 4.7 devel cycle at a very awkward moment for us.) the kactivities situation is really no different than having a dependency on some new 3rd party library. > feature (I think it's important, but I'm biased, obviously), but what about > the KSecretsService work? That's cross-desktop interoperability work we > distro people are all waiting for!) i agree, and i think we're all aware that there is a tradeoff being made here between getting kdelibs features to people in january and getting frameworks to them sooner (with all the features and improvements it will bring). > >> * distro patches (which you keep complaining about, yet it is exactly > >> what the "frozen master" debacle is leading to), > > > > can you point us to these patches so we can deal with them? > > You know those patches very well, they're sitting in your ReviewBoard. ah, you mean your patches which you will put into fedora's version of kdelibs >=4.8. there is nothing forcing you to do that; it's a choice fedora kde is making. > > it's a possibility. we could also choose to work together towards commonly > > beneficial aims. i suppose it is up to us to decide whether it is more > > important to work on the future of kdelibs together (following the team- > > generated decisions) or to put new features into kdelibs for the 4.8 > > release. > > IMHO this is a false dichotomy. I don't see why we can't do both, especially > since the people involved are NOT the same people. (Otherwise we wouldn't > have this discussion in the first place.) > > > at stake is kdelibs progressing and staying relevant in the coming years > > or > > Or what? ;-) we lose opportunities in the mobile space. we lose opportunities to bring in more devs who see themselves as "qt devs" only right now. we lose the patience of some of our larger supporters who are seeing KDE as a whole and KDE's libs as "less relevant" compared to other Qt based projects / communities. we lose the opportunity to get code pushed into Qt5, reducing duplication of both code and effort between Qt and KDE libs. we wait even longer for a well modularized kdelibs, something many of our own app developers have been asking for. none of the above is speculation. i know first hand of specific instances of each of the above situations. > I don't agree that continuing kdelibs 4.x work for a few additional releases > would make kdelibs not progress or become irrelevant in the coming years. > >> (But don't get me wrong, I'm NOT interested in keeping 4.x alive for > >> ages, I'm just interested in 4.x NOW because 5.0 isn't anywhere near > >> ready, even > > > > this is the same argument people used for 3.4 and 3.5. it marred the early > > 4.x releases (along with a few other related issues). > > I also don't agree with this strong claim. I can't see any evidence to > support it. The issues with the early 4.x releases were due to the sheer > amount of changes, which as you say should not be an issue for 5.x. other issues were: * continued effort going into 3.x libs, leaving 4.x efforts to languish. this resulted in not only a 3.4 but also a 3.5. we probably had little choice since at the time apps and workspace devel cycles were tied to library devel cycles. * apps and desktop were coupled tightly to libs development, meaning we couldn't let libs develop without killing apps and desktop progress. which we ended up doing because of that coupling -> it tugged libs development to focus on 3.x, and eventually it made apps and desktop devel halt / slow down dramatically while 4.x libs got into some sort of shape (as we couldn't do libs dev cycles separate from apps & workspaces at the time) * Qt4 being hard to port to from Qt3 code bases * a lack of clearly stated goals up front that covered kdelibs. so we ended up with a variety of things (many of which have turned out quite nicely eventually; some which didn't) going on all at once with very little clear and coordinated direction. (note, btw, that plasma was nowhere near kdelibs at this point in time; it was "merely" having devel hamstrung by Qt and kdelibs ;) the first two issues were very much due to a continued focus on 3.x. the Qt issue was out of our hands, the lack of clear planning was not helped by the lack of focus of 4.x. the Qt issue is being addressed with and for us, and the rest we're trying to do better this time around. > Plus, the issues with the early 4.x releases are one of the things which > made continued 3.5 support necessary and very welcome! But even if 4.0 had > been perfect, stopping kdelibs 3.x feature development back when 4.0 > development got initially STARTED would have hurt 3.5 a lot. let's examine this claim. (subtitled: oh, how i love `git log` :) from 3.5.8 to 3.5.9, there were (by my count) 22 bug fixes, 2 performance improvements and 0 features added. from 3.5.7 to 3.6.8 there were approx 75 commits fixing bugs, 1 that was obviously performance related and 1 feature add. from 3.5.6 to 3.5.7 was similar, but with 2 feature adds (and one feature reverted it seems?) and the rest being bug fixes. 3.5.5 to 3.5.6 had ~4 new features, all of which but one seem to have been done in the 4.x code first, with the one that wasn't being a modification to allow kate 3.5.x to coexist better with kate from 4.x. none of these features were large (in terms of code or individual importance). all the big features during this time were going into the 4.x branch. of the fixes, many were backported from the 4.x efforts. 3.5.x seems to have done just fine. 3.5.1 seems to have been all bugfixes. i didn't bother looking at the rest as it was already taking quite a bit of time. note that i didn't count translations, documentation changes or trivial fixes to code (e.g. compiler warning fixes). as we're not stopping bug fixes in the KDE/4.7 branch (and really, why would we?) and as most features do not appear in kdelibs but in the applications themselves, your concern of stunting upcoming releases seems unfounded. the features in the upcoming 4.8 releases that do not rely on kdelibs features also seems to back that up. > In any case, I > doubt doing that would have improved 4.0 any. (I also think 4.0 wasn't THAT > bad.) it wasn't "bad", but it was very disruptive. worse: workspace and apps were delayed and undeniably hurt by the way libs development was handled. (from Qt through to kdelibs.) > I also need to remind you that (as I already wrote once) libraries have a > much longer shelf life than the rest of the SC: We shipped 4.0 in Fedora 9, > but most of our applications were still kdelibs3-based and benefited from > the kdelibs3 development which was still done at the time! The kdelibs3 > improvements also improved our 4.0-based distribution release and thus the > public's perception of 4.0. And we still ship kdelibs3 now. bug fixes and performance improvements are still welcome in the KDE/4.7 branch. most features don't appear in kdelibs, but higher up in the applications. we'll continue to ship 4.x feature updates of workspaces and apps while frameworks goes through its devel cycle. those three themes repeated often in this email. of course, some features do appear in kdelibs (secret service, kactivities, your package kit integration are all examples), and we want to get those features (and the rest of frameworks' goals) out as soon as we can rather than see frameworks delayed and delayed. (do you know how many features are already in libplasma2 that we're having to wait on? :) > > we can avoid repeating those mistakes by learning from them. > > For that, we first have to identify them. agreed. and we have worked on doing that already in the recent past. > My perception is that the main > mistake in 4.0 was that too many things got rewritten or refactored. agreed. and we're avoiding doing that. how? * by not making introducing major new libraries a priority (though it can happen in the natural flow of things) while we also make other significant changes (e.g. the modularization) * by decoupling the early lib work from workspaces and apps work so that we don't end up with tons of "ripple effects" from the early days of the libs moving around rolling into (and working against) the stable workspace/app efforts. changes in the workspaces and apps will be allowed to happen at their own pace. * by a stated, documented focus on source compatibility * by documenting before we got started what we wanted to achieve (to avoid endless feature sprawl). we need to improve this documentation, and the irc meeting we'll be holding near the end of this month will be a step in doing that. > > * Qt5 is not Qt4: it isn't a huge burdon to port things over. the code and > > API is essentially the same. > > That also implies that forward-porting features developed against kdelibs > 4.x shouldn't be all that hard. no, because frameworks is changing structure and dependencies between libraries ... which makes forward porting more difficult as time goes on. > > this means we have a very reachable goal (not years of work during which > > time kdelibs 4.x will stagnate to death) and we have deadlines we're > > working against (qt 5 ABI change window). > > Merging functionality usually means adding NEW API/ABI, not changing > existing one, so it should be possible in later 5.x releases' feature > windows as well, this doesn't necessarily have to happen in the ABI change > window. agreed, some of the changes don't require changing API/ABI. but, unfortunately, some do. we discovered this unfortunate fact during examinations of when what we'd like to see merged. KUrl -> QUrl is a good example of that. on the flip side, KIon -> QIcon is a good example of a "few missing features in QIcon that can be added later". so there are examples of both, but the API/ABI breakages require we get working now. people have been doing ground work. people like (though not limited to) David Faure and Thiago. people who, at least i, trust to get this stuff as near to "right" as can be expected from a human :) > > but it only happens if we focus on frameworks instead of kdelibs 4.x. bug > > fixes are still fine. and we'll all live just fine without new features in > > kdelibs for a couple releases. we have done so in the past, we will do so > > again in the future. applications have all sorts of features missing and > > needed. > > I think we're already very slow at delivering features to our users (it can > take up to a year if the timing is unfortunate), having a couple release > series (for me, a "release" is e.g. 4.7.3, 4.7 is a "release series") with > no new features at all is going to make this unbearable. have you not noticed the feature additions in kdebase-apps, kde-workspaces, kdeplasma-addons for 4.8.0? kdelibs is not where the bulk of features appear in any given release. > As I already stated back in the early 4.x era, I actually think we need to > find ways to get popular features to our users faster, e.g. by allowing > uninvasive features into point releases as was done in the 3.5.x series. But the feature additions in 3.5.x did not all go smoothly, let's not forget. and how many of those feature adds were in kdelibs, vs in the desktop or applications? (for the desktop, it was almost exclusively in kdebase) > most definitely we should not add MORE delays! we're not. by working on libs first, separate from the workspaces and apps, the workspaces and apps can add features while development continues. even as frameworks development has started, i've overseen numerous feature additions to the workspace modules. have you seen the 4.8 preview videos that have started making their way on to youtube? they are quite nice and show numerous features despite a freeze in kdelibs from dolphin 2 to the more trivial (addmitedly :) picture of the day wallpaper to Plasma Active One .. we're rolling out lots of features. if we kept to the way we working in 3.x days, we'd be stalling all of that work to focus people on 5.x code. instead, we're working on the frameworks first without blocking features in apps and workspaces. iow: less delays. as requested. :) > >> when we're just talking about the libraries/frameworks, let alone when we > >> actually consider applications and/or workspaces building on the new > >> libraries/frameworks. > > > > do you know what that work will entail, or are is this just guessing and > > supposition on your part? because it's not going to be as big as one might > > think due to the SC goals. (plasma workspaces will have some work involved > > as libplasma2 is undergoing some important changes due to QtQuick2) > > Well, what is your ETA? we want to release frameworks as soon after Qt5 as we can. how soon is yet to be determined (largely based on focus that we can train on frameworks development). that relies on the cooperation of libs developers, however. we'll do our best to firm up timelines for frameworks at the meeting at the end of the month, but we will remain focussed on 'when it is ready'. > Do you think Plasma Desktop will be ported to KDE Frameworks 5.x in time > for: > * Fedora 17? (April-May 2012) that would require a time machine, wouldn't it? :) > * Fedora 18? (October-November 2012) doubtful. > * Fedora 19? (April-May 2013) > * Fedora 20? (October-November 2013) possible. but we haven't committed to any dates for that yet. > Also, do you think the ETA will be more dependable than the one for 4.0 > which kept getting pushed back again and again? that is PRECISELY the goal of the program you're pushing back against. we have de-coupled library from workspace and app devel so we can get libraries into early shape first while simultaneously continuing to do workspace and app releases with new features; this allows consistent, timely releases for users and downstreams while not holding up library development. we are (trying) to focus libs devel on frameworks rather than feature adds for >=4.8 so that frameworks development moves forward (as well as not be impeded by having to, with increasing difficulty, merge forward changes made in the 4.x branches) > >> And I believe that most, if not all, people interested > >> in 4.x work right now are in that boat, I doubt 4.x is going to suscite > >> anywhere near the amount of long-term nostalgia 3.x did. We WILL > >> eventually work on 5.x. Just not NOW.) > > > > when, then? after Qt 5 can no longer accept ABI changing merges? > > Well yes, after Qt 5 is actually in a state where it can be packaged, so we you missed the point of my question. the question was not, "when do we move the dependency of Qt in kdelibs from Qt4 to Qt5". the question was, "how long do we have until we can no longer merge things from kdelibs into Qt5". we do not yet require Qt5 for frameworks, and won't for a while yet. > > and why not now? > > Because doing the work now means that, in order to do any sort of testing on > it, I have to build everything from source (and on my own machine, because > I can only use the Fedora build system on stuff that is packaged): the fair enough; so when ever we make this break in development, it has to be when you personally are not working on a new feature. i hope you appreciate how unrealistic that requirement is on kdelibs development, when taken as a whole. > KDE Frameworks and Plasma Desktop (because Frameworks is not a > binary-compatible drop-in replacement for kdelibs 4.x, obviously, so I > can't test anything without also building a matching Plasma Desktop; since it's in a library, and in this case very much does not rely in any way on user interaction or UI outside of libplasma, it should be able to be unit tested very easily. it shouldn't (and doesn't) require Plasma Desktop at all. this, btw, is how i ended up adding the package signing to libplasma. (another GSoC project that is only in frameworks.) with unit tests i could make sure everything there worked as expected, and never once did i build any plasma code outside of kdelibs againts it. > corollary: Whenever Plasma Desktop doesn't compile against Frameworks, I > cannot actually do any runtime testing of my feature!). unit tests ftw. :) > So please realize that the timing of doing the work significantly affects > the workload involved for me. everyone is aware of the workload changes involved. we're all affected by it. we're trying to minimize that affect globally, which means there can be some local pain here and there. > > i'm sorry you reacted that way. more productive might be to consider that > > as your work was indeed reviewed, accepted and welcomed that having it > > debut in frameworks 5 is a great thing. > > Sure, it's going to be a great thing for Fedora because we will be able to > advertise the new feature months (years?) before you. If I really cared only > about Fedora as you're insinuating, I'd LOVE this. But actually, what I see > is that this situation is going to suck for everyone else, which is why I > fought again and again for getting my feature into 4.8. We have this nice > feature, it is all already implemented and ready, why can't we offer it to > our users? From a user's perspective, this makes no sense whatsoever. from a short term "give me everything now" perspective, yes, it doesn't make sense. from a product planning perspective that take the next several years into consideration, it does. i understand that there is gap between those two POV, and that we need to find a way to reconcile them as much as possible. > If you had said "make a version for 5.x and we'll accept it into 4.x as > well", that would have been a motivation to do the 5.x work (and I'd have what we need to keep in mind is that this is not a single instance of this pattern. for you, maybe it is: you only want one feature (the one you've been working on) in the 4.x branch(es). for kdelibs, it's a scenario we are repeating over and over. "do it in frameworks as well as in 4.x" is probably quite close to double the work (more in the case of more trivial features); merging changes (feature improvements, bug fixes, etc.) will become harder and harder as frameworks diverges more and more to the point where merging will be "have git make a patch file, apply it by hand to frameworks" and things will rapidly get messy to the point that frameworks devel will be held up even more, something we can ill afford. if this was the only feature ever to go into both frameworks and 4.x, that might be something very different. but it isn't. there are a number of such features. some are already in frameworks, btw. so the difference between "playing this game just once" and "playing this game many times in the next year" makes a big difference in the decision making. and i understand you are on one side of that table and i'm on the other :) > I would have loved actually discussing the issue with you before the > decision was taken, but I wasn't asked! And now you're actually asking me to there was an open call for the meeting in Randa, which was very well attended by nearly 60 people, most of whom work on kdelibs. during and after the meeting, the results from the meeting were posted here for discussion. no one can be responsible for people missing the discussion if they weren't here to have it. > By the way, I also don't think that allowing applications to pick pieces of > kdelibs / KDE Frameworks à la carte (and otherwise be Qt-only) is a good way > to promote an integrated experience. if an app only needs, say, hardware awareness and get everything else it would otherwise need through the platform plugin, the having Solid a la carte leads to a more integrated experience. the failure in thinking in the past has been that if everything is welded together, then apps will use everything. yes, some will. many will, however, just use nothing. we know this not by theory and philosophy, but by experience and easily documented behaviour. those who want to use everything still can and will even with a componentized frameworks. the difference will be that those who want / need only _some_ functionality just might do so as well, leading to more, not fewer apps, sharing code with KDE and being, as a result, more integrated with our user experience. > think that everything depending on everything is/was a GOOD sign, it means > we reuse(d) code and we care(d) about integration and consistency. And there are still dependencies. they are, however: * more thought out (is that dependency really required, or was it there "just because"? does it actually add something to the library?) * tiered: so there will be "only Qt as a dependency" libraries (we already have those in kdelibs), libraries that depend on those (ditto), and yet other libraries that depend on libraries-that-depend-on-qt-only libraries. iow, there's more attention to intentional design than random sewing-of- things-together. hth ... (from a very tired aseigo at nearly 6am) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
