[Kexi-devel] RFC: plan for starting the Qt5/KF5 port

[Jaroslaw Staniek]

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 <kossebau at 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-devel at 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