And: - astyle-kdelibs is for public libs. Decision whether it is applied to apps and private libs belongs to the given team.
- Please verify if it really 100% works as kdelibs coding style requires. I built 2.05.1 earlier this year (not just a binary from opensuse) and it was broken. For example it did changed nicely formatted args const QString &foo to const QString & foo. A quote from the astyle-kdelibs header: "To fix this, patch astyle with http://www.davidfaure.fr/kde/astyle_qt.diff"; So it's better to patch the tool if you plan to test it. There were other cases when the tool breaks a proper formatting, I don't remember now. - Qt formatting vs astyle-kdelibs: some code is moved outside with an intent to become a Qt-only libs (kreport, kproperty). I wouldn't like to see reformatting happen twice in a row. Conclusion: I'd probably re-examine the tool while porting kreport/kproperty, because it gets not enough attention, please post your results here too. One thing not mentioned here for new repos (predicate, kreport, kproperty) it's possible to do that: http://superuser.com/questions/374673/run-astyle-on-all-files-before-git-commit This is the ultimate fix for formatting without polluting history. On 3 March 2015 at 23:29, Friedrich W. H. Kossebau <kosse...@kde.org> wrote: > Am Freitag, 27. Februar 2015, 19:03:30 schrieb Thorsten Zachmann: >> Hello, >> >> > I say it should be done now, and be done to 2.9 too >> > >> > And I almost don't think maintainers should be able to say no. The long >> > term goal of having a clean codebase is more important than short term >> > issue with git blame (have a separate permanent checkout before this >> > revision where you can run git blame) >> > >> > After all maintainers and developers come and go. It's important all of >> > our >> > codebase is as easy and consistent to look at as possible - and yeah i >> > know >> > that is an argument for keeping easy history too - sigh >> >> There is also the option -w to git blame that ignores whitespace changes. >> Which should be the majority of changes showing a problem. > > So, where are we with the decision about when, where and for which parts to > run astyle-kdelibs? Has anyone already tried how the diff will actually look > like after it got applied? I wanted to give it a try yesterday, but after I > had adapted the seemingly already partially redundant patches for latest > astyle of OpenSUSE, I was stopped by needing "normalizer" from an extended qt5 > build with qtrepotools created, which seems not packaged at least with > opensuse qt5 packages? > > Too bad I only recently freed my disk from any custom qt5 builds... > > So, anyone else who could tell how much the history will be screwed, besides > whitespaces? > > Other than that it seems to me no one now strongly rejects > * astyle-kdelibs being applied to all of Calligra code > * doing that in master > * right before the port starts. > > Does this sounds like something that will make most people happy and least > people unhappy? > > Cheers > Friedrich > _______________________________________________ > Kexi-devel mailing list > kexi-de...@kde.org > https://mail.kde.org/mailman/listinfo/kexi-devel -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
