Hi Luca and everyone else, On 01/12/2015, at 8:00 PM, Luca Beltrame wrote: > Il Tue, 01 Dec 2015 16:10:37 +1100, Ian Wadham ha scritto: > > Hello Ian, > >> between a small number of MacPorts and KDE developers, not "policies", >> patches, reviews and endless email threads. That small group should ask
You are quoting me out of context here… I am NOT talking about abandoning patches and reviews altogether, but clearly there are problems when the submitters and reviewers of patches come from different platforms and are not familiar with each others' technology. I was trying to propose a solution... > Just one small point: IMO reviews are *essential* to ensure that what works > in OSX doesn't break on other platforms. I agree. Pity it does not always work out that way… :-) See https://git.reviewboard.kde.org/r/120431/, which cost me a lot of sleepless nights and anxiety. In essence https://bugs.kde.org/show_bug.cgi?id=337742 was causing DrKonqi to fail on ALL platforms and fail to submit crash reports. I had recently been working with the DrK code on OS X and fixing other problems specific to OS X, so I offered the patch. Apparently nobody else was familiar with the DrKonqi code at the time, so the review was a bit of a schemozzle at first. Eventually Thomas Luebking helped me to develop a simplified patch which was shipped just before a release deadline. And now we reach the bitter bit. Bug https://bugs.kde.org/show_bug.cgi?id=337742 re-surfaced in Linux shortly after the release. Perhaps I should have reminded people that I had only tested the code in OS X. I was assuming that a "review" would include somebody (not the author) independently testing the patch. What worked in OS X did "break on other platforms". The reason was that KDE 4 on Linux was generating KCookiejar entries that poisoned the dialog with Bugzilla, but KDE 4 on OS X did not generate such entries. With the help of some users, I diagnosed the problem, Thomas tested my hypothesis on Linux and we worked out a better patch, which has been working on all platforms for about a year now and has been ported into KF5. Moral: The success or otherwise of patches and reviews depends very much on the individuals involved, their conscientiousness and a shared level of technical understanding between the reviewers and the reviewee. > Policies are social: there's > nothing enforced by "rule". The only rules that I am aware of are > licensing, and the adherence to the CoC and the KDE manifesto. How about the Commit Policy?… ;-) I _hope_ everybody adheres to that... > Personally I think that CI and code review has actually improved KDE > software quite a bit, I believe you. Actually Marko Käning (another Macports-based developer) and Ben Cooksley (sysadmin) set up the first OS X CI for KDE 4 and KF5, with some help from a MacPorts Core Developer. Scarlett Clark now provides those CI's I believe. > so I think the point you're raising here is tangential to fixing the issue. No, the point is not tangential. Better understanding between KDE Core developers and developers working on OS X is essential if we are to progress on that front. On Windows and BSD there are KDE Core developers working already, but there are none on Apple OS X AFAIK, certainly none on MacPorts. My proposal was to set up what is called a Working Party, a small group covering a range of required expertise and representing all "stakeholders" (those people mainly affected by the Working Party's results). It has a defined task, set of objectives and terms of reference, is disbanded when its task is done and reports back regularly to some wider group, such as KDE-Mac and one of the KF5 developers' mailing lists. This is not at all "a style where an elite few make decisions behind closed doors", as Boudhayan imagines. Nor will it undermine patching, reviewing and KDE Policies. It should lead to a climate where patches for KF5 to make it work properly on OS X can be submitted by developers who have a better understanding of what the objectives are and how far KF5 can be modified for use in OS X. The reviews can then be conducted by KDE Core developers who have become more knowledgeable about OS X and its differences from Linux. > That said, I'm just a drive-by contributor, so I have no real idea how > maintaining software for a long time feels like. You're welcome… :-) Cheers, Ian W. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
