[Kexi-devel] RFC: plan for starting the Qt5/KF5 port
Friedrich W. H. Kossebau
kossebau at kde.org
Fri Feb 27 00:36:11 UTC 2015
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>
> > 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
E.g. all the bullet points from
More information about the Kexi-devel