RFC: plan for starting the Qt5/KF5 port

[Friedrich W. H. Kossebau]

Am Freitag, 27. Februar 2015, 22:49:54 schrieb Jaroslaw Staniek:
> On 27 February 2015 at 01:36, Friedrich W. H. Kossebau <kossebau at kde.org> 
wrote:
> > Am Mittwoch, 25. Februar 2015, 09:39:27 schrieb Jaroslaw Staniek:
> >> On 25 February 2015 at 01:01, Friedrich W. H. Kossebau <kossebau at kde.org>
> > 
> > wrote:
> >> > Am Dienstag, 24. Februar 2015, 12:18:29 schrieb Jaroslaw Staniek:
> >> >> On 24 February 2015 at 11:24, Mario Fux <kde-ml at unormal.org> wrote:
> >> >> > Am Dienstag, 24. Februar 2015, 08.51:56 schrieb Jaroslaw Staniek:
> >> >> >> On 24 February 2015 at 03:55, Friedrich W. H. Kossebau
> >> >> >> <kossebau at kde.org>
> >> >> >> 
> >> >> >> > To not have people step on each other toes and do conflicting
> >> >> >> > work,
> >> >> >> > I
> >> >> >> > will add a wiki page where people can "take" a product before
> >> >> >> > they
> >> >> >> > start
> >> >> >> > working on making it build (and where I possibly should also dump
> >> >> >> > this
> >> >> >> > plan). Any proposal for the location and name of the wiki page
> >> >> >> > below
> >> >> >> > community.kde.org/Calligra ?
> >> >> >> 
> >> >> >> Wiki tables unless heavily splited to sections are barely
> >> >> >> interactive.
> >> >> >> Unfortunately (because Kexi should be used for that in the cloud) I
> >> >> >> have to propose a Google docs spreadsheet for real time editing of
> >> >> >> what's done, what's a TODO.
> >> >> > 
> >> >> > Just a quick idea: What about using share.kde.org with WebODF (KDE's
> >> >> > instance of Owncloud)?
> >> >> 
> >> >> Cool but for a spreadsheet structure?
> >> > 
> >> > Sadly not yet there with WebODF. Find us some sponsoring, we WebODF
> >> > devs
> >> > will happily add it if something gets us bread and butter for doing
> >> > that
> >> > instead :) For now it would be e.g. EtherCalc or EtherSheet perhaps
> >> > that
> >> > could be used. Not setup on KDE infrastructure, though. And no real
> >> > experience myself.
> >> > 
> >> > Still, for things I have in mind here todo.kde.org should be a working
> >> > match, no?
> >> 
> >> That's a different tool, not for a sheets that would for example
> >> support a matrix structure (subdir x porting_aspect).
> > 
> > So far I was not planning to use a big matrix, just having products being
> > moved through the states NOTBUILD -> WORKINGON -> BUILDS, and being able
> > to
> > assign a person per product :)
> > 
> > For all the deeper porting work after something builds at least again as
> > the first step, I am not sure people will maintain a big matrix anyway,
> > but rather work on what they just think is fun, organizing themselves
> > dynamically via irc or per email.
> > 
> > And each subproject might have their own approach here anyway. Krita devs
> > might work different from Kexi devs. And the Sheets/Stage/Words/Author
> > crowd has again another dynamic and interaction.
> > 
> > So at least I am hesitating to prepare more here :)
> > 
> > But might make sense still. Tell, what items would make up the
> > porting_aspect dimension?
> > 
> > E.g. all the bullet points from
> > https://community.kde.org/Frameworks/Porting_Notes ?
> 
> I think so,

That will be an awfully large matrix.
Will it be fun to maintain it? How to add/maintain intermediate states, when 
e.g. third of the code was only done for a certain porting step so far, when 
the person had no more time?
Will people really take the needed care? I just added version "2.9.0" to 
bugs.kde.org for almost all of Calligra apps... 
I really doubt we all have the discipline needed (well, I know I run in danger 
of not having it :/ ), even if we might have best intentions at the begin.
Not sure how long the gamification by some metrics would motivate...

But hey, what about the rest here? Do you not care, and will also not care 
about that port tracking tool?
Will you declare by the honor of your , and what will you do as punishment if 
you don't? ;) (promises are so cheap)

Also: who would set this matrix up initially? :)

> and also whatever scripts we found/know to be useful;
> mention them there.
> Like port-qslots.sh (absent in the above page?). Also the astyle thing.
> Everything, even if something applies only to some code.

Sure, but that could also be added to the wiki, and there will not be that 
much such additions that a wiki page will not work.

> Junior engineers ask me which aspect of porting can they contribute
> to. The matrix would guide us and show the progress.

True. But only if the matrix is maintained. I surely could be done for 
subprojects in Calligra, where the involved people are eager enough.

Have KReport and KProperty been ported following such a detailed matrix? Was 
it really missing?

Cheers
Friedrich