> On Oct. 5, 2014, 7:43 a.m., Ben Cooksley wrote:
> > As this is needed to restore the functionality of Dr Konqi, can someone 
> > familiar with the codebase please review it so we can get this in?
> 
> Ian Wadham wrote:
>     Perhaps I am the person most familiar with the codebase of Dr Konqi, 
> having worked on it for a few months now.
>     
>     So, if nobody else steps forward within the next 24 hours, I will do my 
> own "Ship It" and commit to KDE 4 kde-runtime master in time for Thursday's 
> close of the KDE 4.14.2 bugfix release.
>     
>     If KDE core developers want the Dr Konqi bugs fixed in KF5, they will 
> have to forward-port this change and my earlier changes themselves. I cannot 
> do that. I work on Apple OS X and we do not have KF5 and Qt 5 building there 
> yet.
>     
>     I do not propose to address Thomas's comments. I have more important 
> things to do.
> 
> Albert Astals Cid wrote:
>     With my release team hat:
>      - Sure commit to master if you can't find someone else to review and you 
> *know* your code is right and you're going to fix it when/if it break
>      - No, don't commit to KDE/4.14 this is a huuuuuuuuuuuuuge change and I 
> don't feel like it is guaranteed to go in, you can be a good guy and review 
> https://git.reviewboard.kde.org/r/120376/ since it seems that one fixes the 
> immediate problems people are having, no? (you say you're the one that knows 
> the code more yet have not reviewed it, why?)
>      - Your obsession to not contribute to KF5 based versions will byte you 
> again when you decide to move to KF5, you should really rethink it. Because  
> we do have KF5 and Qt5 building on MacOsX according to at least one of the 
> members of the MacOSX team, no?
> 
> Marko Käning wrote:
>     I wouldn not phrase it an "obsession to not to contribute to KF5". ;)
>     
>     In fact, it has been pointed out multiple times on KDE-MAC, in pm as well 
> as in various RRs, that the "MacOSX team" at the moment mainly tries to get 
> KDE4 into a working state, which is why Ian wants to push this forward.
>     
>     And yes, we have KF5 on Qt5 in a state where my OSX/CI(/Jenkins) systems 
> are able to build and install many projects successfully.
>     BUT, unfortunately, this does NOT mean that I am able to RUN every of 
> these apps successfully, as the OSX/CI system's specifics (being that all 
> frameworks, libs and apps live in their own install roots) in conjunction 
> with a (still missing) working QStandardPaths patch lead to the problem that 
> most of the apps can't find their config and data files at runtime at this 
> point in time. :(
>     
>     As I am *alone* on KF5, I haven't managed to proceed with the 
> QStandardPaths issue, since many other things kept me far too busy (like the 
> inclusion of new projects on OSX/CI, dealing with Jenkins master [also for 
> Linux], tending project dependencies, creating a KDE4.13 branch on our 
> macports-kde git repo, testing KDE4 applications, etc...).
>     
>     Eventually I conclude herewith that the "MacOSX team":
>     
>     - does contribute directly to Qt5/KF5 big time - althought it is only me 
> ATM,
>     
>     - does indirectly contribute to Qt5/KF5, as many RRs can be modified 
> easily for inclusion into KF5, as it has happened already for e.g. 
> https://git.reviewboard.kde.org/r/119847/ and 
> https://git.reviewboard.kde.org/r/119848/ 
>     
>     - believes that 1st priority should be to get KDE4 in good shape on OSX, 
> which is why Nicolas wants to release KDE 4.13.3 this week and will proceed 
> with 4.14.x right afterwards,
>      
>     - needs decent user feedback with valuable backtraces which is why a 
> non-dysfunctional DrKonqi is required on all OSX versions, hence this RR.
> 
> Thomas Lübking wrote:
>     Screw OSX ;-)
>     
>     Afaiu DrKonqui is dysfunctional due to bugzilla server changes atm. (bug 
> #337742) what means either this or review 
> https://git.reviewboard.kde.org/r/120376/ more or less *has* to go into KDE 
> SC4 - regardless on whether it's required for exotic OS' or not.
>     
>     @Ian, please attach Jekyll Wu, George Kiagiadakis, Matthias Fuchs and 
> Dario Andres Rodriguez, they've been the main submitters to bugzillalib.
> 
> Ian Wadham wrote:
>     Feel free to cancel anything I may commit, Albert, but you could be doing 
> both yourself and KDE software (4 and 5) a disservice. Bug 
> https://bugs.kde.org/show_bug.cgi?id=337742 will remain...
>     
>     I only said "perhaps" in my statement about the codebase, hoping someone 
> more knowledgeable would step up.
>     
>     If you will read the Description of this review (Note 2) and the dialog 
> in https://git.reviewboard.kde.org/r/120376/ you will find that I have 
> already had some input to the other review and given it some thought.
>     
>     Last week I was expecting a core developer who knows Dr Konqi to review 
> both patches, but nobody did. This week I have a course to prepare, for 
> presentation tomorrow, so I have no time, and KDE 4.14.2 closes on Thursday. 
> I do not even know whether Frédéric has commit privileges.
>     
>     One swallow does not make a summer. Only Marko Kaening can build KF5 and 
> Qt5, on his personal setup, and he is having great difficulties getting 
> applications to run - even such a simple one as Bovo. There is also a 
> technical difficulty on MacPorts in providing Qt4 and Qt5 libraries 
> simultaneously. The MacPorts Qt port developer is working on it. It seems 
> that KF5 and Qt5 will not be generally available on Apple OS X for several 
> weeks or months. We are currently concentrating on getting a reliable release 
> of KDE 4.13 into production on MacPorts...
>     
>     Re my attitude to KF5. I have offered the current patch to anyone who 
> wants to take it into KF5. As you know, I am very old and have already spent 
> 10 or more years as a KDE developer. I decided, early this year, to retire 
> from KDE development. KF5 was the clincher. I have no desire to engage in any 
> more library-induced "porting" of applications. I consider it boring, 
> counter-productive and quite contrary to my personal and professional 
> philosophy, which is to make library and operating environment changes as 
> inconspicuous as possible to application writers and end-users, thus 
> maximizing *their* productivity.
>     
>     I say this with my (pre-retirement) core-developer, system architect and 
> release-team hat on.
> 
> Ian Wadham wrote:
>     @Thomas, I could only get Dario Andres and Jekyll Wu in the space allowed 
> by ReviewBoard. Too bad.
>     
>     Glad you are starting to see things my way, except for the comment about 
> OSX... :-) I really am finding some serious problems in KDE 4's core code, 
> mostly affecting OSX only, but some reaching out into KDE4/Linux&Windows or 
> even KF5... :-(
> 
> Albert Astals Cid wrote:
>     > Feel free to cancel anything I may commit, Albert, but you could be 
> doing both yourself and KDE software (4 and 5) a disservice. Bug 
> https://bugs.kde.org/show_bug.cgi?id=337742 will remain...
>     
>     I thought you said that the other patch would fix the immediate issue? If 
> so that other patch which is much simpler is what should go to the stable 
> branches, no?
>     
>     > I only said "perhaps" in my statement about the codebase, hoping 
> someone more knowledgeable would step up.
>     
>     Ok :/
>     
>     > If you will read the Description of this review (Note 2) and the dialog 
> in https://git.reviewboard.kde.org/r/120376/ you will find that I have 
> already had some input to the other review and given it some thought.
>     
>     Sorry for complaining you had not commented when you actually had :/ 
> Totally my fault :(
>     
>     > Last week I was expecting a core developer who knows Dr Konqi to review 
> both patches, but nobody did. This week I have a course to prepare, for 
> presentation tomorrow, so I have no time, and KDE 4.14.2 closes on Thursday. 
> I do not even know whether Frédéric has commit privileges.
>     
>     I'll ask again because I may not be understanding the whole picture. Does 
> https://git.reviewboard.kde.org/r/120376 fix the immediate issue people is 
> seeing? If it does in my opinion that is what should go to 4.14, your more 
> future-proof solution but also more complex and thus prone to introduce new 
> issues should go to master for release December.
>     
>     > One swallow does not make a summer. Only Marko Kaening can build KF5 
> and Qt5, on his personal setup, and he is having great difficulties getting 
> applications to run - even such a simple one as Bovo. There is also a 
> technical difficulty on MacPorts in providing Qt4 and Qt5 libraries 
> simultaneously. The MacPorts Qt port developer is working on it. It seems 
> that KF5 and Qt5 will not be generally available on Apple OS X for several 
> weeks or months. We are currently concentrating on getting a reliable release 
> of KDE 4.13 into production on MacPorts...
>     
>     Ok, I may have misunderstood how good was the state of KF5 on Mac.
>     
>     > @Thomas, I could only get Dario Andres and Jekyll Wu in the space 
> allowed by ReviewBoard. Too bad.
>     
>     I added the other two people in there for you.
>     
>     > Glad you are starting to see things my way, except for the comment 
> about OSX... :-) I really am finding some serious problems in KDE 4's core 
> code, mostly affecting OSX only, but some reaching out into 
> KDE4/Linux&Windows or even KF5... :-(
>     
>     I am not sure what is "your way" here, can you please ellaborate?

@Albert: It would be a help if I could know how to do that point-by-point 
commenting with sidebars email-style. I can find nothing about it in RB 
Markdown Reference...

Re https://git.reviewboard.kde.org/r/120376: the patch looks good to me, but I 
have not downloaded it and tested it myself and would want to do that before 
"shipping" and committing it. I am not convinced that "token" is OK as a 
parameter name in some places, as opposed to "Bugzilla_token". The Bugzilla 
doco seems to say the latter, but it is a bit vague in places... Also that 
patch would conflict with mine. So a bit of footsying around with git (locally) 
might be needed. I do not think I will have time tomorrow (Wednesday my time: 
Tues UTC 20:00 to Wed UTC 07:00), so maybe Thursday. This where being 11 hours 
ahead of UTC can be an advantage... ;-)

Re introducing new issues, I have centralised the main changes precisely to 
avoid that. Of course, that has involved relocating a fair few snippets of 
code, which raises the line-count of the patch-file. The main addition to the 
code is quite large, but not very complex compared to some things in 
KGoldrunner or Palapeli.. :-)

Would I have to commit to both master and KDE/4.14 branch? I have lost track of 
how you are doing KDE 4 releases now. The fix will be in the kde-runtime repo.

Thanks for adding the people.

Re "my way": I hope Thomas will know what I mean. He has seen that there is a 
rather bad bug to be fixed here. That is what I was commenting on. I guess it 
gets down to form vs. function, style vs. substance and perception vs. reality. 
I am a firm believer in the second of the two alternatives in each of the three 
cases.


- Ian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120431/#review67946
-----------------------------------------------------------


On Oct. 7, 2014, 7:42 a.m., Ian Wadham wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120431/
> -----------------------------------------------------------
> 
> (Updated Oct. 7, 2014, 7:42 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Runtime, Ben Cooksley, Darío 
> Andrés Rodríguez, George Kiagiadakis, Jekyll Wu, and Matthias Fuchs.
> 
> 
> Bugs: 337742
>     http://bugs.kde.org/show_bug.cgi?id=337742
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> -------
> 
> When bugs.kde.org changed over to Bugzilla 4.4.5 in July 2014, the security 
> method used by Bugzilla changed from cookies to tokens that had to be 
> supplied as parameters with every secure remote-procedure call. Further 
> changes to security methods have been announced by Bugzilla and are 
> documented for unstable 4.5.x versions of Bugzilla software. Tokens will be 
> deprecated and then discontinued. When this happens, Dr Konqi will need to 
> supply a user-login name and a password with every secure remote-procedure 
> call. Furthermore, the traditional "User.login" call presently used by Dr 
> Konqi will be deprecated and discontinued.
> 
> This patch fixes the tokens problem, which has given rise to several bug 
> reports https://bugs.kde.org/show_bug.cgi?id=337742 and duplicates. It also 
> provides for automatic switching to passwords-only security as and when the 
> Bugzilla version changes again. This uses
> a general data-driven approach which can be easily updated, ahead of time, 
> next time Bugzilla announces a change that affects Dr Konqi, whether it be in 
> security methods or some other feature.
> 
> NOTES:
> 1. This patch is intended to be forward-portable to Frameworks/KF5, but I 
> work on Apple OS X, where it is not yet possible to run Frameworks/KF5 and do 
> the porting and testing. So could someone else please do it?
> 2. Another Review Request https://git.reviewboard.kde.org/r/120376/ addresses 
> the tokens issue only, but it should be reviewed and shipped as a matter of 
> urgency, both in KDE 4 and Frameworks, the next bug-fixing release for KDE 
> 4.14 being due for tagging on Thursday, 9 October. That will leave more time 
> for this review (120431) of my more long-term and more general patch.
> 3. The passwords-only part of my patch is currently storing the password in 
> clear. Suggestions re encryption are welcomed --- or the code could be 
> changed to make use of KWalletD mandatory (but that might not be fully 
> portable to all platforms).
> 4. When the Bugzilla call "User.login" is discontinued, some re-sequencing of 
> the flow of KAssistantDialog pages will be needed. I have not attempted to do 
> that at this stage. Probably the entry of the user name and password should 
> be delayed until the report has been accepted by the Dr Konqi logic and it is 
> just about to be sent to bugs.kde.org or attached to an existing bug report.
> 
> REFERENCES:
> http://www.bugzilla.org/docs/
> http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN
>  Bugzilla 4.5.x (future) API doco re security
> http://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/WebService.html#LOGGING_IN
>  Bugzilla 4.4.5 (current) API doco re security
> http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/User.html#login
>  User.login will be DEPRECATED in 4.5.x
> 
> 
> Diffs
> -----
> 
>   drkonqi/bugzillalib.h 570169b 
>   drkonqi/bugzillalib.cpp f74753c 
>   drkonqi/reportassistantpages_bugzilla.h b7af5b8 
>   drkonqi/reportassistantpages_bugzilla.cpp 22183f0 
> 
> Diff: https://git.reviewboard.kde.org/r/120431/diff/
> 
> 
> Testing
> -------
> 
> Used the bugstest.kde.org database and KDE 4 master on KDE/kde-runtime 
> repository.
> 
> Tested a range of version numbers (see commented-out test data) against a 
> range of 5 or 6 hypothetical and real Bugzilla versions at which things could 
> or will change. This was to test the basic version-checking and 
> feature-choosing algorithm.
> 
> Tested submitting both full reports and attached reports, using both the 
> token method and the passwords-only method.
> 
> Also tested with KWalletD supplying the username and password on Dr Konqi's 
> login dialog.
> 
> 
> Thanks,
> 
> Ian Wadham
> 
>

Reply via email to