RFC: plan for starting the Qt5/KF5 port

[Jaroslaw Staniek]

On 3 March 2015 at 23:18, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
> 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?

They are not ported. I'd set up such a matrix too keep TODOs in a sane
state for them.
How it's maintained for other code is beyond me but not noting down
the progress and plans in the public won't help because it won't show
that help is needed.

Wikis or not, the tables will be of nontrivial size, and markup makes
editing hell.
My aversion to large wiki tables is that they are structured. If I
have no time I'd more likely click on a cell of google doc and enter
DONE, instead of CTRL+F in a fragile TEXTAREA of a web browser.

I don't declare what would others say or what workflow do they prefer :)

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