... sure there might be some difficult parts... but still don't see the point... I assumed the whole idea of GSoC is to learn something? Not sure how you learn by tip-toeing around the difficult parts... I thought some resistance is needed to learn. And even if they fail... still don't see a problem there... still a great opportunity to learn. And finally: all PRs - GSoC or not - are reviewed... and we have tests all over the place. I say let them try... but again, I think it's early... Do we know if we get accepted? If not - can happen - then all this effort for nothing... until then I think there is enough work to do... so let's pick tickets.
On Fri, Nov 6, 2026 at 4:49 AM Aman Mittal <[email protected]> wrote: > Hi Aleks, > > My main concern is that command processing requires someone who is highly > familiar with the Fineract codebase. It will inevitably touch many parts of > the codebase. And a dedicated mentor (who is at least a committer) who can > guide candidates on how to approach the codebase and resolve their > concerns. If anyone is willing to volunteer as a mentor, I have no problem > with that. If you have a recommendation for someone who can guide a > candidate for this that would be great. > > While in general gsoc discussion is early. I think it is better this way. > It will give the community enough time to review gsoc efforts and manage > expectations early. This will ensure contributors keep discussions public > rather than repeatedly direct messaging any PMC member or potential mentor. > > > > On Fri, 6 Nov, 2026, 8:43 am Aleksandar Vidakovic, < > [email protected]> wrote: > >> Why not command processing? I would argue that we should really make an >> effort to address even more of the technical debt (hint: new ticket in that >> category "type safe queries" FINERACT-2022)... and the new command >> processing is addressing a lot of it... I will circle back soon on the >> idempotency feature to get the most pressing thing out of the way. In >> general I'd say the whole discussion about next year's GSoC is a bit early, >> isn't it? >> >> On Thu, Nov 5, 2026 at 2:29 PM Aman Mittal <[email protected]> >> wrote: >> >>> Hi, Personally I recommend to not considering command framework for >>> upcoming gsoc unless any committer actually wants to mentor this. And some >>> ongoing PRs are still yet to merge. (It also affect the core fineract so we >>> will be very careful in this one) Any core fineract idea must have PMC >>> approval and dedicated committer as mentor. >>> >>> You can consider other fineract side projects. >>> >>> Regards >>> Aman >>> >>> >>> On Thu, 5 Nov, 2026, 6:22 pm Ádám Sághy, <[email protected]> wrote: >>> >>>> Hi >>>> >>>> The real reason why the new command framework is not targeting these >>>> endpoints are the missing capabilities which are not addressed yet: >>>> >>>> - idempotency handling >>>> - maker-checker >>>> - etc >>>> >>>> >>>> Regards, >>>> Adam S >>>> >>>> On Nov 5, 2026, at 12:28 PM, Abhishek Chaudhary < >>>> [email protected]> wrote: >>>> >>>> Hi all, >>>> >>>> While looking at Savings for GSoC 2027 ideas, I noticed that the 2026 >>>> GSoC page excluded the loan and savings packages from the >>>> command-processing project "to prevent interference with Pepper Soup >>>> efforts": >>>> https://cwiki.apache.org/confluence/spaces/FINERACT/pages/421958555/GSOC+Summer+2026 >>>> >>>> While searching on "what pepper soup is" (I thaught it was a phrase), I >>>> stumbled on 2024 Mifos post ( >>>> https://mifos.org/blog/pepper-soup-enhancements/) and got to know >>>> Pepper Soup as sponsored upstream work focused mainly on loans, COB and >>>> performance. >>>> >>>> I had two questions: >>>> 1. Is that work still ongoing, and does its current scope include >>>> Savings, for example the Savings COB work in >>>> https://issues.apache.org/jira/browse/FINERACT-2332? >>>> 2. Would stability work on Savings interest posting, such as tests and >>>> bug fixes, be open to a GSoC 2027 project, or should GSoC stay clear of >>>> that area? >>>> >>>> Thanks, >>>> Abhishek >>>> >>>> >>>>
