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

[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, 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.

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

-- 
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