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 <i...@lysator.liu.se> wrote: > > On Friday, January 16, 2015 09:26:37 Jaroslaw Staniek wrote: > >> On 16 January 2015 at 09:14, Inge Wallin <i...@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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
