[phpMyAdmin Developers] GSoC 2018

[Deven Bansod]

Hi Xinyu,

On Sat, Feb 24, 2018 at 7:54 PM, meteorlxy <meteorlxy.cn at 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