Developers of Sympa

[David Verdin <address@concealed>]

Hi Soji,

It's important to think about it. Other people have tried to refactor 
Sympa and fail; It's important that this one be the good one.

To answer Soji's main question: On my opinion, we can't just drop 6.2 
right now because too many people use it and rewriting Sympa from 
scratch is doomed from the start.

What we need is a smooth transition between 6.2 and 7.0. I am definitely 
in favour of option 2.

What I like in Soji's plan:

- we coordinate development. I think the failures in the past were due 
to a lack of coordination between developers who, often, did not know 
the software enough and made changes without truly understanding their 
implications.

- we encourage knowledge of the soft by enforcing documentation and testing

- modifications are thoroughly thought before being done.

- we stabilize 6.2 and prevent the kind of troubles we had recently. We 
address actual and current issues for Sympa users.

- we prepare a sane codebase before going through the deep changes that 
should occur in 7.0

What I dislike:

- we do refactoring in 6.2 which, on my opinion, should be a maintenance 
branch, in which only bug fixes should be done. I fear we break things. 
But then again, some bugs can be fixed only through refactoring.

- Some developers would like to start working on 7.0 right now, and 
start experiment new ways of running Sympa code. That can't be done in 
soji's proposal and there is a risk that what they would do in a 
separate project would become incompatible with 6.2 code

- I can't pinpoint the threshold between 6.2 codebase improvement and 
real 7.0 code. The thing is: one day or another, we will make changes 
that won't be compatible between 6.2 and 7.0. These should not occur 
before we're done working on 6.2.

So here is an alternate version of Soji's proposal:

A- Everything in 6.2 is done according to his plan:

  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.

B - Nothing moves in 7.0 as long as we work on 6.2, except synchronizations.

C- People can start orthogonal projects that will be useful for 7.0 but 
will not be impaired by 6.2 changes. For example:

    1. Dancer root implementation

    2. DBIx::class schema

    3. Sympatic

D- A schematic documentation of Sympa behaviour is developed in 
parallel. The aim of this documentation is to explain Sympa generic 
behaviour and user stories, in order to preapre the 7.0 work. For 
example, we could explain what can happen to a mail; What a user will do 
in the web / REST interface. etc. This would help developers-to-be 
understanding whet they do and also could help us plan the 7.0 development.

Well, that's about it.

What do you think?

Regards,

David


On 23/03/2018 10:10, 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.
>
>                                   *
>
> 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.
>
>
>                                   *
>
>
> 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.
>
>
>                                      *
>
> What do you think?
>
>
> Best regards,
> -- Soji

--
"Mieux vaut viser la perfection et la rater que viser la médiocrité et 
l'atteindre."
- Francis Blanche

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature