hi Kevin, 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.
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. 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. 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 and then brought here to k-c-d for further discussion. to ignore would be disrespectful of the time honoured principles in KDE. > 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) > * 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) > * 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? > * maybe even an outright fork like Trinity (of KDE 3) or MATE (of GNOME 2). 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. at stake is kdelibs progressing and staying relevant in the coming years or > (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). we can avoid repeating those mistakes by learning from them. now, 5 is not 4, and this also makes a difference as to why we should shift more focus to frameworks. why? well: * Qt5 is not Qt4: it isn't a huge burdon to port things over. the code and API is essentially the same. * we aren't going for "add lots of huge new functionality blocks" (e.g. solid, phonon, threadweaver, sonnet, etc. etc. etc.); this is a maintenance reorganization, an opportunity to merge functionality into Qt5 (which has a definite time deadline, btw, which we need to meet or else we lose that opportunity entirely) and a chance to alter some behaviour in our code that is most appropriate for a major release (though some things of this nature could be done post 5.0 as well) 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). 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. > 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) > 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? and why not now? now is as good a time as any. using your reasoning, we can delay it continuously .. at some point "not NOW" has to become "NOW" and we decided in summer, which gave everyone LOTS of lead time on this, that "NOW" is indeed "now" > In addition, this situation might actually push some contributors NOT to > work with you on 5.0 material. we already have that situation, don't we? > I can tell you that your refusal to get my > libplasma PackageKit work into 4.8 definitely did demotivate me from doing > any work on the 5.0 version. 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. focus on the development and progress rather than the negatives in the tradeoffs. there are ALWAYS tradeoffs, such as: "if we decide to make this a '4.8 or else i quit!' power struggle and we refuse to work together on frameworks 5, then we end up missing the Qt5 merge opportunities, we'll lose opportunities to have our libraries used in other Qt5 aps and efforts in the mobile area will be utterly fucked." there are always tradeoffs. let's examine which are best to take and then move in that direction without fear and with each other's support. > That said, considering the 4.8 release schedule, it is now really too late > to reopen kdelibs 4.8 for feature development anyway. :-( It should have > been done when I originally asked for it a month ago (or even better, it > should never have been closed down in the first place!). please do not rewrite history. see my comment from 3 months ago on August 11 to your initial review request: https://git.reviewboard.kde.org/r/102291/ "this work needs to shift to being written against the frameworks branch, and then only after libplasma2 has been merged into it. note that in libplasma2, there is no PackageMetadata class and the install package routine has moved into PackageStructure as well." you were given a heads up not a month ago, but 3 months ago, along with the offer of help to make that merge happen. -- 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.