Two repos prepared for porting to Qt 5
Adam Pigg
piggz1 at gmail.com
Fri Jan 16 12:21:15 GMT 2015
I'll port k report, unless anyone else has a burning desire to
Sent from my BlackBerry 10 smartphone.
Original Message
From: Jaroslaw Staniek
Sent: Friday, 16 January 2015 12:17 PM
To: Inge Wallin
Reply To: Calligra Suite developers and users mailing list
Cc: Calligra Suite developers and users mailing list; kexi-devel at kde.org
Subject: Re: Two repos prepared for porting to Qt 5
BTW, update from Ben Cooksley, personal repos are supposed to be r-w
for everyone, just push force is there enabled.
This way you can undo a commit easily (where admin rights would be
needed if calligra.git was used).
On 16 January 2015 at 12:09, Jaroslaw Staniek <staniek at kde.org> wrote:
> 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
--
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
_______________________________________________
calligra-devel mailing list
calligra-devel at kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
More information about the calligra-devel
mailing list