Re: Request: remove libkactivites from kdelibs (in experimental/)
Hi, On Monday 14 November 2011, Aaron J. Seigo wrote: 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. to throw in my two cents: I don't think the problem is the _amount_ of communication. But personally, I'm dearly missing a _central_ place with a plain summary of the most important status information about kdelibs. My main focus of development is on a KDE-based application, not kdelibs. But every once in a while, I find a bug in kdelibs, and I want to contribute a fix. And every once in a blue moon, I want to contribute a small feature. For such sporadic contributions, the ratio of time spent on producing a patch versus time spent on figuring out how to get the patch into kdelibs is not a good one. Back in the good old days, this basically meant reading up on any freezes in effect. With the move to git, and now with frameworks efforts, the complexity has increased, considerably. All relevant information is available somewhere, but having to search through half a dozen places (techbase.kde.org, community.kde.org, kde-core-devel, kde- cvs-announce, blogs, dot, ...) is downright painful. Esp., if some of those places are littered with outdated and misleading bits. So, what I would love to see is _one_ short up-to-date page with just the most relevant info along the lines of: - You want to contribute a bug fix with no API changes, and no string changes: Commit to branch X. Additionally, merging your commit into branch Y would [not] be helpful but/and is [not] necessary. - You want to contribute a bug fix with no API changes, but changes in i18n strings: Please wait until MM.DD. - You want to do X: Commit to branch Z - For non-trivial patches, please get your code reviewed, first: git.reviewboard.kde.org - Here are some links to current background information on plans and schedules: X, Y, Z, and here's a step-by-step guide on pushing patches to kdelibs with git. Ideally, this page would be linked from http://quickgit.kde.org/?p=kdelibs.gita=summary , if that is possible. Ideally, also, git would point we to it, when my push fails for some reason. Regards Thomas signature.asc Description: This is a digitally signed message part.
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Monday, November 14, 2011 10:35:16 Thomas Friedrichsmeier wrote: My main focus of development is on a KDE-based application, not kdelibs. But every once in a while, I find a bug in kdelibs, and I want to contribute a fix. And every once in a blue moon, I want to contribute a small feature. For such sporadic contributions, the ratio of time spent on producing a patch versus time spent on figuring out how to get the patch into kdelibs is not a good one. Back in the good old days, this basically meant reading up on any freezes in effect. With the move to git, and now with frameworks efforts, the complexity has increased, considerably. the complexity will eventually subside. right now it's something like: * until further notice, if it is a bug fix, put it into KDE/4.7 and it will get merged forward into frameworks * if it is a feature, do it in a branch off of frameworks and when it is ready, it can be merged in it is complex because we currently have to juggle between 4.x freezes, frameworks progress and the evolving state of that effort in a branch. it's a transition period that we all want to be as _short_ as possible so we can get back to simple. in future it will be: * bug fixes can always be applied to the stable branch; these will get merged into master. * features can be opened at any time in a feature branch and merge into the testing branch when they are ready for testing by your fellow developers. when it is ready for merging, it'll get merged into master. notice the lack of discussion there about freezes. all you'll need to know as a casual contributor is where feature branches come off of and what the latest stable branch is, and whether your addition is a bug fix or a feature. for casual contributors, this should be very low-barrier-to-entry. you shouldn't even need to consult the release schedule for things like feature freezes :) All relevant information is available somewhere, but having to search through half a dozen places (techbase.kde.org, community.kde.org, kde-core-devel, kde- cvs-announce, blogs, dot, ...) is downright painful. Esp., if some of those places are littered with outdated and misleading bits. completely agreed. So, what I would love to see is _one_ short up-to-date page with just the most relevant info along the lines of: that is one of the primary reasons we're getting together on irc later this month. it is quite clear to everyone that this is sorely needed, and so we're going to make this thing along with some other supporting information for frameworks ... -- 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.
Re: Request: remove libkactivites from kdelibs (in experimental/)
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
Re: Request: remove libkactivites from kdelibs (in experimental/)
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. 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. 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. In particular, nobody asked us distro people for it: I don't recall any sort of notice about this issue to kde-packager. Yet scheduling is definitely something which needs to be discussed with distro packagers. The need in my case is that we are going to ship my feature in Fedora 17 (This is not negotiable. It's already a release later than I had initially hoped for, but at least in Fedora, missing a freeze window only delays you for 6 months. I really miss the time where the same thing was true for all the KDE SC modules. Sadly, judging from the kdepim fiasco first and now 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. 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 my GSoC proposal, I didn't even THINK that there'd possibly be no kdelibs 4.8, 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). 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. I don't dispute that a maintainer is ALLOWED to do so, but that doesn't make it a good idea. 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.) 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. 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? 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 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.) to ignore would be disrespectful of the time honoured principles in KDE. No, it would simply be realizing you made a mistake! 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. * separate git repositories (which in fact is exactly what you are doing with libkactivities! yes, because that is the shape the frameworks
Re: Request: remove libkactivites from kdelibs (in experimental/)
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
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Friday 11 November 2011, Aaron J. Seigo wrote: 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. I'd prefer if there wouldn't be a separate mailing list for the frameworks effort, but if it would use k-c-d instead. IMO this _is_ kde core development. This would make it more public (yes, it is completely public, but still a bit hidden if you didn't subscribe the frameworks list). ... 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 ... and into CMake, which is making good progress btw. :-) (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) ...also for our buildsystem :-) Alex
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Friday, November 11, 2011 16:50:00 Alexander Neundorf wrote: On Friday 11 November 2011, Aaron J. Seigo wrote: 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. I'd prefer if there wouldn't be a separate mailing list for the frameworks effort, but if it would use k-c-d instead. IMO this _is_ kde core development. This would make it more public (yes, it is completely public, but still a bit hidden if you didn't subscribe the frameworks list). you might be right. the concerns that were raised was that k-c-d has gotten pretty noisy and at times the place where the proverbial peanut gallery comes to hang out ;) i'm not sure a separate list was the best idea, however it the signal-to-noise ratio was the motivation. * 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 ... and into CMake, which is making good progress btw. :-) yes i've been sort-of-kind-of following that and its looking pretty promising indeed! :) integrated automoc ftw... -- 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.
Re: Request: remove libkactivites from kdelibs (in experimental/)
Aaron J. Seigo wrote: On Monday, November 7, 2011 16:35:57 Albert Astals Cid wrote: Maybe we should really resurrect the existence of a master 4.8? unecessary imho, and runs the extreme danger of repeating the 3-4 debacle with kdelibs where people just keep working on the stable release and don't care enough for the next important release of libs. You cannot really FORCE volunteers to work on what you want them to work on. Preventing them from working on what THEY want to work on will just lead to them moving their work elsewhere, e.g.: * separate git repositories (which in fact is exactly what you are doing with libkactivities! Talk about hypocrisy…), * distro patches (which you keep complaining about, yet it is exactly what the frozen master debacle is leading to), * maybe even an outright fork like Trinity (of KDE 3) or MATE (of GNOME 2). (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 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. 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.) In addition, this situation might actually push some contributors NOT to work with you on 5.0 material. 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. So you achieve exactly the opposite of what you're trying to achieve. 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!). Kevin Kofler
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Friday, November 4, 2011 23:05:28 Aaron J. Seigo wrote: we currently have libkactivities in kdelibs/experimental. due to upcoming changs and frameworks 5 development, it has been moved into its own git repository: kactivities. unless there are any further objections, here is what i plan to do after the release of 4.7.4 on December 6 (so as not to disrupt 4.7 releases): kdelibs: in KDE/4.7 branch: * remove the contents of kdelibs/experimental/libkactivities * put a README in its place stating what happend so people can easily know what to do now that it is gone in frameworks branch: * merge those changes, then delete the libkactivities directory altogether in that branch kde-workspace: * merge my libkactivities branch into master -- 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.
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Sunday, November 6, 2011 10:29:56 Allen Winter wrote: Do you mean to remove it from the kdelibs-4.7 branch? it should definitely be removed from kdelibs-master, if it hasn't been already. KDE/4.7 and master are currently the same thing. so i'm requesting removal from both, essentially. -- 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.
Re: Re: Request: remove libkactivites from kdelibs (in experimental/)
A Dilluns, 7 de novembre de 2011, Aaron J. Seigo vàreu escriure: On Sunday, November 6, 2011 10:29:56 Allen Winter wrote: Do you mean to remove it from the kdelibs-4.7 branch? it should definitely be removed from kdelibs-master, if it hasn't been already. KDE/4.7 and master are currently the same thing. so i'm requesting removal from both, essentially. I can see a problem with the next 4.7.x release then :-/ I mean i'm all for dropiing killing changing experimental libs, but not between 4.7.3 and 4.7.4 Maybe we should really resurrect the existence of a master 4.8? Albert -- 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
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Friday, November 04, 2011 23:05:28 Aaron J. Seigo wrote: we currently have libkactivities in kdelibs/experimental. due to upcoming changs and frameworks 5 development, it has been moved into its own git repository: kactivities. i would like to request approval to remove it from kdelibs/experimental and make the kactivities repository a dependency for kde-workspace. the benefits: * libkworkspace drops 4 classes (essentially halfing it in size) * we have one place for libkactivities so people don't continue to get confused the drawbacks: * a new module required for building kde-workspace note that this module is already a dependency for the plasma-mobile repository. If we can recreate the tarballs as we used to, and Dirk indicated we can, then I think this is a good solution to this headaching problem. We promised packagers not to break up tarball layouts before Frameworks 5 any further, but we can split up repos as long as we keep reassembling them for releases, which is already the case for kdegraphics, for example. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Monday, November 7, 2011 16:35:57 Albert Astals Cid wrote: A Dilluns, 7 de novembre de 2011, Aaron J. Seigo vàreu escriure: On Sunday, November 6, 2011 10:29:56 Allen Winter wrote: Do you mean to remove it from the kdelibs-4.7 branch? it should definitely be removed from kdelibs-master, if it hasn't been already. KDE/4.7 and master are currently the same thing. so i'm requesting removal from both, essentially. I can see a problem with the next 4.7.x release then :-/ I mean i'm all for dropiing killing changing experimental libs, but not between 4.7.3 and 4.7.4 assuming 'business as usual' and once 4.8.0 is out we do not do a 4.7.5 (or whatever release) AFTER 4.8.0 is out, then i'm just fine with waiting until then. i would still like to do it in the stable branch of kdelibs rather than open up master due to this as this should not take focus off of frameworks. Maybe we should really resurrect the existence of a master 4.8? unecessary imho, and runs the extreme danger of repeating the 3-4 debacle with kdelibs where people just keep working on the stable release and don't care enough for the next important release of libs. we've already solved one set of issues by de-coupling workspace and apps from the libs development, and i'd like to see the other issue of ah well, it's more useful (short term) to work on stable than the next major release also be addressed. we can only do this if we do not concentrate, or allow for work to concentrate on, kdelibs stable but instead push ourselves towards frameworks. i understand the temptation, but i don't like what the outcome will almost certainly be (indefinite delay of frameworks 5). let's learn from our past :) -- 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.
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Friday 04 November 2011 6:05:28 PM Aaron J. Seigo wrote: hi .. we currently have libkactivities in kdelibs/experimental. due to upcoming changs and frameworks 5 development, it has been moved into its own git repository: kactivities. i would like to request approval to remove it from kdelibs/experimental and make the kactivities repository a dependency for kde-workspace. Do you mean to remove it from the kdelibs-4.7 branch? it should definitely be removed from kdelibs-master, if it hasn't been already. the benefits: * libkworkspace drops 4 classes (essentially halfing it in size) * we have one place for libkactivities so people don't continue to get confused the drawbacks: * a new module required for building kde-workspace note that this module is already a dependency for the plasma-mobile repository. for the KDE SC 4.8 release, I think this is already the situation. and for KDE SC 4.7.4 and above.. I guess that's something for the packagers.
