Developers of Sympa

["Stefan Hornburg (Racke)" <address@concealed>]

On 03/23/2018 10:10 AM, IKEDA Soji wrote:
> Hi Sympa develpers,
> 
> 
> Recently I'm losing my confidence that Sympa 7 will emerge in
> someday.
> 
> The biggest difficulty is refactoring on current code, I feel:
> Sympa 6.2 includes numerous features added by various people, and not
> a few of them have problems --- undone implementation (see e.g.
> GH#231 [1]), broken logic (e.g. GH#235 [2]), code not thought out
> well (GH#234 [3]), duplicate codes (found everywhere), ..., and most
> of them are hardly documented in the beginning.
> 
>   [1] https://github.com/sympa-community/sympa/issues/231
>   [2] https://github.com/sympa-community/sympa/issues/235
>   [3] https://github.com/sympa-community/sympa/issues/234
> 
> I gave very recent examples above, but most of bug fixes and changes
> we have dealt with in this one year (and more) are something like
> them.  As soon as someone starts refactoring, they will be in maze
> due to problems above.
> 
> Thus, I think of proposing two things.

Yes, I agree there are lot of things to fix in the current codebase. Still we 
should have
a vision for Sympa 7 - I will detail my vision of it below.

> 
>                                  *
> 
> First: Should we throw Sympa 6.2 away?
> 
> If answer was "yes", we might not consider the second proposal below,
> and could start writing Sympa 7 from scratch soon.  In this case
> Sympa 6.2 would be dying gradually.
> 
> I feel this option is not so bad from view of mental health of
> community.  Only disadvantage is that Sympa 7 at the end will
> definitely lose compatibility with Sympa 6.2 or earlier.
> 
> If answer was "no", since we would have to find the way to achieve
> both improvemnt (rather repair) of Sympa 6.2 and production of
> Sympa 7, I will send a proposal afterward.
> 
> 
> Please let us know the answer of your own.
> 
> Then, after you answered, please read following.
> 

There is certainly no reason to throw Sympa 6.2 away, as it is used 
extensively by people
out there. Even if we manage to get written Sympa 7, we should maintain Sympa 
6.2 for a few
years beyond that.

> 
>                                  *
> 
> 
> Second: Change the way of refactoring.
> 
> Everyone says that we have to introduce unit test framework into
> development of Sympa. However, we have not acomplished it.  I think
> the reason is clear: Anyone don't have knowledge enough about what
> is written in code, or even if they know, don't share knowledge.
> 
> Either by trial in the past (during pre-6.2) or by recent trial by
> David on sympa-7.0 branch, I feel that we could not get satisfactory
> result --- One of our goal was to write unit test.  However,
> including almost only "use_ok" and "isa_ok" is not the unit test (it
> proves just that module can compile).  The result will be the same if
> the other worked. --- We don't know what we should include further.
> 
> As a solution, I propose to proceed refactoring on sympa-7.0 branch
> as below:
> 
>   1. Write POD of module in question to reflect behavior of the
>      module _clearly_.  Until we have finished writing, we must not
>      touch the code.
> 
>      In fact, we may find mistakes and/or defects in the code.  We
>      won't repair code at once, but will describe desirable behavior
>      (instead of broken behavior) in POD. (See also note below.)
> 
>      We may also want to propose new feature or improvement.
>      However, since we are writing POD describing existing code,
>      such things should not be included in POD.  You may propose
>      them at appropriate place else.
> 
>   2. Next, write unit test covering entire interface described in POD
>      above.  We should include enough number of cases to test
>      possible behavior (again, calling each method once at a time is
>      not unit test).
> 
>   3. At last, we put our hand to actual code in source.
> 
>        - We repair problems found on 1. above.
>        - We refactor the code in true meaning.
> 
>      This step will last until the code will pass all ceses of unit
>      test.
> 
> Note: If a problem found while we carrying out steps 1. and 2. is
> more or less severe, it may be fixed on sympa-6.2 as necessity (and
> fix may be merged into sympa-7.0).  Anyways, we should not touch the
> code on sympa-7.0 before step 3.

In my opinion it doesn't make much sense to rewrite the code base as is - too 
daunting,
too much new bugs and on top of that it is not rewarding to tackle a 
humongous task like
that.

I would break it down in several projects which can

* coexist with Sympa 6.2 codebase
* written with unit tests in mind

The outline of the projects would be roughly:

* DBIx::Class schema
* REST API
* Modern web interface using the REST API
* Config manager
* Daemons (Task manger, ...)

Regards
          Racke

> 
> 
>                                     *
> 
> What do you think?
> 
> 
> Best regards,
> -- Soji
> 


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.