Two repos prepared for porting to Qt 5

[Inge Wallin]

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?

> 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