Two repos prepared for porting to Qt 5

[Jaroslaw Staniek]

On 16 January 2015 at 11:49, Inge Wallin <inge at lysator.liu.se> wrote:
> I am sorry, this was sent by mistake to jaroslaw alone. :/
>
> Here is what I wrote
>
> ------------------------------------------------
>
> On Friday, January 16, 2015 09:47:51 you wrote:
>> You'd work like on github, use pull request (via filing on
>> reviewboard). Scratch repo assumes it's the repo owner who integrates
>> the changes. He's the integrator. There are also personal clones, you
>> pull the kproperty there for example.
>
> This sounds very cumbersome.  Another question is how would you update your
> own copy to mirror the newly integrated patches?

You can merge and even pull-rebase. All the repos are visible at
http://quickgit.kde.org and there's nothing different than github
workflow.
Decision to use either workflow is individual for given case. We're
entering special time and it will quickly I get back to norm hope.[1]
I'll be waiting for feedback from contributors actually involved.

We have qt5 predicate branches in official repo already too and use
the principle of "only owner writes there" but for this is only a
gentleman agreement.

[1] But 'one big repo' approach won't come back, BTW.

>> When history gets rewriten and dirs are massively moved here and
>> there, I see no point in having multiple-writes type of repos.
>
> Why would history be rewritten?  This never happened to any big extent in the
> kde edu cases. And I would *strongly* recommend to not combine porting with
> refactoring but do one after the other is finished.
>
>> Rejecting this workflow is another topic. There are just two workflows
>> the above being for special (short) time.
>>
>> On 16 January 2015 at 09:26, Inge Wallin <inge at lysator.liu.se> wrote:
>> > On Friday, January 16, 2015 09:26:37 Jaroslaw Staniek wrote:
>> >> On 16 January 2015 at 09:14, Inge Wallin <inge at lysator.liu.se> wrote:
>> >> > On Friday, January 16, 2015 01:26:20 Jaroslaw Staniek wrote:
>> >> >> Hi,
>> >> >> For those willing to work on porting, two repos have been created:
>> >> >>
>> >> >> git clone kde:scratch/staniek/kproperty
>> >> >> git clone kde:scratch/staniek/kreport
>> >> >>
>> >> >> These are files cut off from calligra/2.9, with history.
>> >> >> It's best if you work in own scratch repos.
>> >> >
>> >> > Why this?  That makes all cooperation impossible. The best thing would
>> >> > be
>> >> > if somebody took the effort to port the CMakefiles to use KF5 but after
>> >> > that it should be possible for anybody to port individual aspekts of it
>> >> > independently, right?
>> >>
>> >> Well, imagine that at this early stage I had to push with -force
>> >> already once for these repos... not something expected in calligra/
>> >> It's just not ready for use, porting these libs within calligra/ does
>> >> not seem justified to me: we'd fix paths for example to reflect
>> >> conventions of Qt 5 but paths and namespaces will change after
>> >> extraction to separate libs => extra work.
>> >
>> > That's not what I was replying to. My point was that "It's best if you
>> > work in own scratch repos." makes no sense since it will be impossible to
>> > cooperate.>
>> >> BTW, these two are only used by Kexi and no refactoring happen, just
>> >> semi-automatic work. And after all these are easier libs so give us
>> >> get some real experience.
>> >>
>> >> > At least, that is how it has worked in kde-edu and that gave no
>> >> > problems
>> >> > whatsoever.
>> >> >
>> >> >> Porting hints: https://community.kde.org/Kexi/Porting_to_Qt%26KF_5



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