Next release schedule/plans
Hi Since the tickets and things I want to do may have varying duration, I would like to know if there is any schedule/plan set for the next major release. Depending on the timeframe, I could switch from small tickets to bigger ones more easily. On a side note, is there any rule regarding the merge requests in the project? I'm not used to this kind of tool outside company projects where there are rules like 'another contributor approval is needed' or 'every single change must go through a merge request'. For the small fixes I am pushing so far, asking for a review may be overkill… Regards Pierre signature.asc Description: This is a digitally signed message part.
Re: Next release schedule/plans
It has always been the rule that minor changes that you feel confident about is just pushed. Changes to architecture or user experience should be put up for review, and possibly even discussion. We have never required complete approval, but should carefully listen to objections and not do changes before there is at least acceptance. You are co-maintainer of Words already so that gives you a big voice in how things should go As for my own co-maintainership - I'm willing to give it up if you like as I will probably not have time to do actual coding. On the other hand I do continue to monitor as long as you don't ask me to step down Camilla. On 13/02/2021 11.20.55, Pierre wrote: Hi Since the tickets and things I want to do may have varying duration, I would like to know if there is any schedule/plan set for the next major release. Depending on the timeframe, I could switch from small tickets to bigger ones more easily. On a side note, is there any rule regarding the merge requests in the project? I'm not used to this kind of tool outside company projects where there are rules like 'another contributor approval is needed' or 'every single change must go through a merge request'. For the small fixes I am pushing so far, asking for a review may be overkill… Regards Pierre
Clazy fixes and CI…
Hi In order to rejuvenate a bit some parts of the code base, I am looking into Clazy, especially the old-style connect fixit. In several projects, switching away from these made the application more reliable, with issues being catched at build time instead of run time. Do you see any reason not to do that? I plan to do it on words and its libs first since that's what I will test the most, but if you want I can do it on the whole project. After that cleanup is done, I will start looking into setting up a CI and running the unit tests we have automatically in gitlab. I think this could lower the entry barrier for new/junior developers… If somebody else already tried/did that, any feedback/hint/help is welcome obviously. Cheers Pierre signature.asc Description: This is a digitally signed message part.
Re: Clazy fixes and CI…
I'd say just do it. The code i work on at work uses the new style too, and apart from a few places with overloaded signals or slots it is really easy to work with On 13/02/2021 14.43.59, Pierre wrote: Hi In order to rejuvenate a bit some parts of the code base, I am looking into Clazy, especially the old-style connect fixit. In several projects, switching away from these made the application more reliable, with issues being catched at build time instead of run time. Do you see any reason not to do that? I plan to do it on words and its libs first since that's what I will test the most, but if you want I can do it on the whole project. After that cleanup is done, I will start looking into setting up a CI and running the unit tests we have automatically in gitlab. I think this could lower the entry barrier for new/junior developers… If somebody else already tried/did that, any feedback/hint/help is welcome obviously. Cheers Pierre
Re: Clazy fixes and CI…
Definitely support that effort as well, they are /much/ nicer to work with just all 'round, and even if we can only depend on Qt 5.6, we /can/ depend on a sufficiently modern compiler for our code to be less... ancient ;) So yeah, definitely go for it :) On Saturday, 13 February 2021 13:52:22 GMT Camilla Boemann wrote: > I'd say just do it. > > The code i work on at work uses the new style too, and apart from a few > places with overloaded signals or slots it is really easy to work with > > On 13/02/2021 14.43.59, Pierre wrote: > Hi > > In order to rejuvenate a bit some parts of the code base, I am looking into > Clazy, especially the old-style connect fixit. In several projects, > switching away from these made the application more reliable, with issues > being catched at build time instead of run time. > Do you see any reason not to do that? I plan to do it on words and its libs > first since that's what I will test the most, but if you want I can do it on > the whole project. > After that cleanup is done, I will start looking into setting up a CI and > running the unit tests we have automatically in gitlab. I think this could > lower the entry barrier for new/junior developers… If somebody else already > tried/did that, any feedback/hint/help is welcome obviously. > > Cheers > > Pierre -- ..dan / leinir.. http://leinir.dk/
Re: Clazy fixes and CI…
On Saturday, February 13, 2021 3:24:35 PM CET Dan Leinir Turthra Jensen wrote:
> Definitely support that effort as well, they are /much/ nicer to work with
> just all 'round, and even if we can only depend on Qt 5.6, we /can/ depend
> on a sufficiently modern compiler for our code to be less... ancient ;) So
> yeah, definitely go for it :)
>
Work is in progress then:
https://invent.kde.org/office/calligra/-/merge_requests/16
Some old style remain due to the use of Q_PRIVATE_SLOT.
Do we want to use Qt features marked as, I quote, "for use in private Qt APIs
only"?
This can be worked around for connect with a lambda, like
QObject::connect(findStrategy.dialog(), &KFindDialog::okClicked,
q, [this]() { q->d->startFind(); });
But if these are to leave and never come back, I'd much rather get rid of them
and not work around them :)
signature.asc
Description: This is a digitally signed message part.
