KF5 Volunteer day 2 next week?
Hello, It occurred to me that we didn't have such a volunteer day in March yet. What about having one on Saturday 24th? (almost last opportunity to have one in March) Who would be available to lead it like we did with Aaron and David on the previous edition? Advantage is that it would align with the monthly Toulouse Hacking session. And I know of at least one person there who would be interested (doesn't necessarily mean he'd show up though) The catch is that I won't be available saturday next week, but it's not a blocker IMO. Such volunteer days can clearly run without me, we just need a couple of savvy people. So, doable? Any volunteers (aha) to drive the volunteer day? :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Workflow Idea for 4.10
On Friday 16 March 2012 21:31:11 Alexander Neundorf wrote: Sounds good. But OTOH, having one workflow for KDE frameworks (i.e. not even all of KDE SC) would be also a really good thing to have. It will make contributing easier. That's pretty much Aaron's point yes. And I clearly see the value in it of course. I've to take into account the current drawbacks identified with the current proposal too though. Would 2) be an option for KDE frameworks ? Could be[*]. But as you probably gathered from my previous email I'm purposefully not jumping on a definitive choice just yet. More options to investigate and consequences to take into account. Regards. [*] If we were to bless a single one, it's the one with most chances to make it as the one size fit all one in my books ATM. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Workflow Idea for 4.10
Hello, On Saturday 17 March 2012 19:23:27 Stephen Kelly wrote: Am I the only person who values browsable history? Repositories where you can run gitk and see something useful. No, you can count me partly in. :-) That said, you shouldn't make the issue worse than it really is. Part of that is a tool issue, we have no good way to vizualize such an history... the real question is: yet? If that's something we can count to see solved later on then no big deal, if not then we have a large upcoming problem which will explode as we use more branches. What Aaron proposed is exactly what CMake does. The result is that if you run gitk, you can't see the actual patches. If you run gitk --first-parent on master you *only* see merges, so the only information you can see is the name of the branch that got merged (which is in the git commit message), not the actual patch, and to see the patches in a topic you have to know the name of the topic. You can't just browse the commits, so you can't practically do post-commit review with gitk, as I do. Using email for that really doesn't work for me for one thing. If I want to look at commits that I vaguely know exist but I don't know which topic branch it came from, I should be able to browse fot that. I have the git repo in front of me, so I should be able to use it without jumping through too many hoops. We're going to have small repos after splitting, not large ones. Having a branch and a merge per patch commit in small repos is way overkill. Let's have readable history instead please. As I pointed out earlier on, *for KDE Frameworks* and because of the splitting, the currently proposed workflow is clearly overkill in most cases. That was my main motive to step back and reevaluate the situation. [...] I think people think that if they're committing in a branch which is not master, that they are 'free' and their commits don't have to build, and that all that matters is that the end result actually gets merged, but that's not really true. We should have history which is both readable and buildable imo. +1, that's the important point which is often overlooked when leaning toward let's feature branch often. The other one which is kind of linked to that, is that it makes it much easier for someone to end up being more isolated, working in the branch for too long reducing communication. Part of the way we get to that is by not encouraging everyone to make lots of branches, encouraging people to have branches in scratch repos if they want to have a branch, and encouraging people to submit to master self contained patches which build instead. Yep, one of my investigations taking into account the profile of the contribution (as mentionned previously) instead of the profile of the component leans toward a similar solution. Making commits that don't build and making mistakes is understandable of course especially for new people (and I sometimes make commits that don't build too), but we should at least aim higher. Agreed. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Volunteer day 2 next week?
On Sunday 18 March 2012, Kevin Ottens wrote: Hello, It occurred to me that we didn't have such a volunteer day in March yet. What about having one on Saturday 24th? (almost last opportunity to have one in March) Who would be available to lead it like we did with Aaron and David on the previous edition? Advantage is that it would align with the monthly Toulouse Hacking session. And I know of at least one person there who would be interested (doesn't necessarily mean he'd show up though) The catch is that I won't be available saturday next week, but it's not a I'm also busy next Saturday. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Fwd: Review Request: Make KAuth ready for frameworks + API Changes
For interested people (hopefully many) -- Messaggio inoltrato -- Da: Dario Freddi d...@kde.org Date: 18 marzo 2012 23:25 Oggetto: Review Request: Make KAuth ready for frameworks + API Changes A: Kevin Ottens er...@kde.org, David Faure fa...@kde.org, Alexander Neundorf neund...@kde.org Cc: Dario Freddi d...@kde.org, kdelibs kde-core-de...@kde.org, Dario Freddi d...@kde.org, kdelibs kde-core-de...@kde.org This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/ Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf. By Dario Freddi. Description Preamble - sorry for having to name-call people but apparently we still don't have a frameworks way for reviewing code (which sucks). And sorry for the long summary, but it's worth reading. However. This huge patchsets brings KAuth in the marvelous world of Frameworks. If you dislike ReviewBoard's way of displaying diffs or simply want to see a commit list, please refer to the URL in Branch. First of all, I pulled in a dependency on KJob after a chat with Kevin. This makes KAuth tier2, but shouldn't be a big issue. Then there's the hard part: source compatibility is reasonably broken here. The changes I had to do were mostly for the sake of revamping the internal workflow of the library. The main problem KAuth had was the fact it was completely synchronous, leading to a multitude of problems. After these changes it's fully asynchronous instead (reason for pulling in KJob), the API was simplified, and some unused features like multiple action execution have been removed. The main changes at a glance: * Some renaming to the enums * Moving Action ActionReply to be implicitly shared * Removing ActionWatcher (now useless due to the new semantics of execute * Removing some useless APIs from Action, namely executeActions, execute(helper) * execute() now returns a KJob * helperID() - helperId() * Static action replies are now static accessors returning a new instance. This was a complete mistake in the first place, but it's still there with a different semantic to ease porting. The main use case for changing this is a failure to handle implicitly shared classes in multithreaded environments with that approach. Of course, while it would be awesome to have all the code reviewed, I understand it's a very big change so I'd like at least some feedback on the following points: * General sanity of the new API * Consistency of the enums. StatusInvalid vs. ExecuteMode vs. AuthorizationDeniedError. While the semantic seems correct to me, I'd like to have some feedback on whether consistency is valuable in the ordering of typevalue vs. valuetype and which one should be preferred in case. * Whether to deprecate static accessors such as static const ActionReply SuccessReply(). I strongly favor this. * Whether the new dependency of kcoreaddons for the sake of using KJob is reasonable or I should go for a different alternative. * CMake sanity for the new dependency of kcoreaddons. The code is pretty much unit-tested and it should have a decent coverage, even if I had no way to check this. For unit tests, I had to create a fake authorization backend for testing purposes, whereas I managed to reuse the dbus backend for helper communication, so that I could even test that. For running the helper and the client in the same process, in the unit test I am resorting to making the dbus service of the helper live in a separate thread, to prevent asynchronous DBus calls from failing due to QDBus' local-loop optimization. The test is also run on the session bus. Testing New unit tests pass 100% Diffs - staging/kauth/CMakeLists.txt (PRE-CREATION) - staging/kauth/autotests/BackendsManager.h (PRE-CREATION) - staging/kauth/autotests/BackendsManager.cpp (PRE-CREATION) - staging/kauth/autotests/CMakeLists.txt (PRE-CREATION) - staging/kauth/autotests/HelperTest.cpp (PRE-CREATION) - staging/kauth/autotests/SetupActionTest.cpp (PRE-CREATION) - staging/kauth/autotests/TestBackend.h (PRE-CREATION) - staging/kauth/autotests/TestBackend.cpp (PRE-CREATION) - staging/kauth/autotests/TestHelper.h (PRE-CREATION) - staging/kauth/autotests/TestHelper.cpp (PRE-CREATION) - staging/kauth/src/AuthBackend.h (PRE-CREATION) - staging/kauth/src/CMakeLists.txt (PRE-CREATION) - staging/kauth/src/HelperProxy.h (PRE-CREATION) - staging/kauth/src/backends/dbus/DBusHelperProxy.h (PRE-CREATION) - staging/kauth/src/backends/dbus/DBusHelperProxy.cpp (PRE-CREATION) - staging/kauth/src/backends/dbus/org.kde.auth.xml (PRE-CREATION) - staging/kauth/src/backends/fake/FakeBackend.cpp (PRE-CREATION) - staging/kauth/src/backends/fakehelper/FakeHelperProxy.h (PRE-CREATION) - staging/kauth/src/backends/fakehelper/FakeHelperProxy.cpp (PRE-CREATION) - staging/kauth/src/backends/mac/AuthServicesBackend.cpp (PRE-CREATION) -
