Hi Xinyu,
On Sat, Feb 24, 2018 at 7:54 PM, meteorlxy meteorlxy.cn@gmail.com wrote:
Dear PMA Team,
My name is Xinyu Liu, a graduate student from Xi'an Jiao Tong University(XJTU), China. I've been using phpmyadmin for a long time, and I really want to catch the opportunity to be a contributor of phpmyadmin.
Thanks for your interest in contributing to the project.
As for my skills, I'm familiar with Laravel (not CakePHP yet) and webpack. (I have some small repos on my github [https://github.com/meteorlxy])
That's great. CakePHP is not generally used inside phpMyAdmin per se, but we do use it in our Error Reporting server. It'd be good to have its knowledge if you are applying for a project related to Error Reporting server.
I'm insterested in the topic 'Introduce modern JS features and tools to phpMyAdmin codebase' in the idea list. I think modularization of js code is necessary, but that needs lots of code refactor and may cause many issues. As pma providing release version, we have to use something like webpack to convert the modular source code to production files.
I'm not so clear about where should I begin, as it may need entirely code refactor to the js codebase. Your guidance will help a lot.
Thanks for your interest in the idea.
You are absolutely right in saying that this would involve a lot of refactoring. You can look at various parts of our present JS code and evaluate what features and modularization principles (and how best) can be applied to the codebase, how can webpack be introduced to our codebase.
For your proposal, you may want to come up with a plan/schedule on how would you go around with handling different parts of the codebase. Also, evaluating how can you let the untouched parts continue to work as it is. This would be extremely important if you think, that it may not be possible to cover the complete codebase in twelve coding weeks.
As mentioned on the ideas list, we would be targeting our development efforts towards 5.0. This would be a major feature release and the development would go around in the master branch, while the bug fix versions for 4.8.x would be taken care of from a different branch. So, this should not be a *big* problem. But your proposal plan should involve the process for handling part-upgrades of the codebase, since we would not want to leave the codebase in a broken state for too long.
Hope that cleared some of your doubts. Feel free to write back to the mailing list with any specific questions.
Regards, Deven Bansod