RFC: plan for starting the Qt5/KF5 port

[C. Boemann]

On Friday 27 February 2015 01:21:56 Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 25. Februar 2015, 15:41:33 schrieb Boudewijn Rempt:
> > On Wed, 25 Feb 2015, Dmitry Kazakov wrote:
> > > Hi!
> > > 
> > > My 2 cents :)
> > > 
> > > 1) astyle
> > > 
> > > Last time astyle was applied to Krita code (something around 2010-2011,
> > > it
> > > was applied partially?) I really didn't like the result. At least the
> > > thing it did with braces and indentation. I guess we just need to choose
> > > really carefully what to change and what not. E.g.
> > > one-line-return-if-error ifs might not have braces. That is I don't
> > > agree
> > > that the policy statement "Use curly braces even when the body of a
> > > conditional statement contains only one line" should be followed
> > > blindly.
> > > 
> > > For the rest, e.g. include style, tab vs spaces, lines with trailing
> > > whitespace I'm ok with fixing it automatically.
> > > 
> > > 2) If astyle applied, it must be applied to master-only. Under no
> > > circumstances to calligra/2.9. Without being able to use 'git blame'
> > > it'll be tough to fix many kinds of bugs and do bisecting.
> > 
> > Okay.
> 
> If not using astyle on calligra/2.9, then it should be better only applied
> at the end of the porting, close to 3.0 release, to not complicate forward
> porting of commits to calligra/2.9. Would you agree?
> Perhaps also even only after 3.0, during 3.1, when the chances are even
> lower that stuff needs to be forward ported from 2.9.
> 
> So okay if I move that item to a section "Stuff to be done after the port"?
> 
> Cheers
> Friedrich
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel

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