RFC: plan for starting the Qt5/KF5 port

[Friedrich W. H. Kossebau]

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 ?

Cheers
Friedrich