Hi everyone, 2012/9/22 Frederik Gladhorn: > > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105972/ > > Ship it!
in my opinion, the "Ship It!" button should be pressed only by the maintainer or another core developer of the application. I have clearly stated in my review that some parts of the request are not acceptable in the current form, in particular adding the public function KItemListView::layouter(). I have offered to test the new feature and then change the public API of the affected classes in a better way, but nobody bothered to comment on my statement that the build system of KMag, which is required to test the feature, is broken and that I can't build it. Maybe you expected me to fix KMag myself. I could have done this, of course, but I really don't have much time for working on Dolphin, and I prefer to spend it working on the items on my own (very long) TODO-list. What I find even more unfortunate than the unacceptable unautorised push is the way the changes show up in the history now. I actually like tools like "git log", "git blame", and qgit a lot, I like it when the history looks clean, and I always thought that the main point of review requests is to bring the proposed change in a form that can be included in one, or maybe a few, logically structured commits. But the history is now a big ugly mess. Having commits like, e.g., https://projects.kde.org/projects/kde/kde-baseapps/repository/revisions/e6d4a935c8d03dcfda65e0b2f92d243b18a411e3/diff in the repository is really pointless. I know that this commit has been done after comments from me, but the version of the files that did not respect the coding style should not have been pushed to the public repository in the first place. The space that these dozens of pointless commits take up in the repository is maybe not a big concern nowadays, but they make examining the history (which I sometimes do to find the cause of a regression) very, very painful. Well, the damage has been done, and there is no way to fix it now. But I kindly ask you not to do any major changes in Dolphin code, in particular changes in header files, ever again without discussing this with the Dolphin core maintainers and getting approval. Thanks for your understanding. Another point that we have not discussed yet is who will maintain the accessibility classes in the future. If this code is included in Dolphin, I want to know who will take care of any bugs that users will find. Frank
