Developers of Sympa

[David VERDIN <address@concealed>]

It's that ime of the year when I'm thinking. Don't want it wasted, so I'll 
share my thoughts with you.

First: we're bickering about version numbers and web site whereas we should 
be focusing in doing the same work as Soji: develop Sympa.
Second: Marc and I made a first, if small, step towards Sympa 7 by writing a 
test file on Bulk.pm. It is incomplete of course as the main challenge in 
Sympa is to make a module testable by taking into account the numerous 
dependencies inherited from 20 years of evolution.
Third: Before summer, I started to write test files on Conf.pm and 
SympaDatabaseManager.pm, which were incomplete too but achieved the same 
goal: make these files testable. I had some very productive discussions with 
Soji and Racke at the time, which helped making it work smoothly in Sympa.
Last: Soji is the guy in charge of Sympa 6.2, we all agreed on it. Though it 
does not mean we can't discuss his choinces (I had a few says on the 6.2.34) 
it means that, as long as we are not productive, it is up to him to decide 
how and when to release. As far as I followed, he always took time to create 
pre-releases and to plan ahead release dates. And the few times when real 
problems arose, he accepted to delay release dates until the problem was 
fixed. All in all, he kept Sympa alive while taking community advice into 
account.

All of this makes me think about the way to Sympa 7, as Soji wrote.

1- The Sympa code will need a deep refactoring, what Soji already started in 
Sympa 6.2 (just look at the Spindle directory for example) and I understand 
he plans to continue this work, when needed.
2- The only way to prevent regression is to have a testable code.

So I think that we should put our efforts towards implementing a full test 
framework in the current Sympa 6.2. In addition to making this branch more 
reliable (that's the pint of tests after all) it would have the benefit to 
force us to understand fully the current code base. I know the Sympa code 
base very well but there are also a lot of recent parts that I need to dig in.

So here could be the plan: cover the whole Sympa 6.2 code base in unit tests, 
without changing the code. Then only, we could work on Sympa 7, a work that 
would be eased by the understanding bornt from our work on tests.

Of course, some parts of the code we'll test will probably disappear replaced 
by third party modules. But I don't think our time would be wasted, because 
we would know exactly what we need to achieve with these modules.

What do you think?

Regards,

David

----- Original Message -----
From: "IKEDA Soji" <address@concealed>
To: "sympa-developpers" <address@concealed>
Sent: Saturday, 29 September, 2018 08:33:46
Subject: Re: [sympa-developpers] speaking about versioning

Marc,

Yesterday you told you plan to report what caused by defect with
6.2.34 in a university.

My answer is already given: "Who are you saying that?".

6.2.34 was preceded by two beta pre-releases.  "The lack of beta
cycle"?  Ha!  The fact is that you have never joined any tests.
Don't pass the buck.

Criticizers may tell anything they want to tell, only if they were
not or they forgot they are insiders. --- No, Marc, you look exactly
an uninvolved bystander.

# Honestly, I have realized some defects of 6.2.34 early in the next
# day of its release.  But, if it would fuel empty sermon as he
# wrote, it is vain to propose release of fix.  Furthermore, they might
# not affect features my users (my company and customsers) were using
# at that time. ;-/


In some days I'll write about things I haven't written much: Funding,
relation with the other organizations especially RENATER, the way of
development, path to Sympa 7 etc. It may contain some unpleasant
things for some readers.  I apologyze in advance.

Though in my mind, I'd not like to waste time by such bubbling...


Regards,
-- Soji

On Thu, 27 Sep 2018 07:45:36 +0200
"Stefan Hornburg (Racke)" <address@concealed> wrote:

> On 9/26/18 10:37 AM, Marc Chantreux wrote:
> > hello,
> > 
> > semantic versioning for sympa7 was acted during the
> > hackathon but what about the 6.* ?
> > 
> > * some of us just can't trust the current so called
> >   stable release because of the lack of beta cycle.
> >   stability is very important for very large
> >   organizations using sympa. Soji does a great job
> >   providing assistance on github but obviously, he
> >   can't catch every flaws so we need a real beta cycle
> >   time.
> > * also those very large organizations cannot afford
> >   a very to update to every new stable release
> >   (damn true when instability and regressions are in
> >   the corner) so i still think we we need to slow
> >   down the release cycle.
> > * on the other side, maybe some little sites can
> >   handle the release pace of 6.2
> > * the lack of beta cycle is a problem
> > 
> > i was thinking about a way to improve the situation
> > with the current release cycle. that's my proposal:
> > 
> > * Soji moves from 6.2 to 6.3, releasing the pace that
> >   sounds good for him.
> > * Whenever something is know up and running fine
> >   by large sites who want to contribute to beta test
> >   (universalistes for sure but we can ask for friends
> >   to jump in...  framalist, unistra, ...), we pick that
> >   version to become a 6.4.something.
> > * whenever there is a breaking change, we can increment
> >   the minor.
> > 
> > i see avantages:
> > 
> > * semantic versionning for sympa6 (so newcomers are not
> >   confused about to )
> > * let Soji run the pace he wants but trying to avoid
> >   the problems he can't handle by his own.
> > 
> > regards,
> > marc
> > 
> > 
> 
> My two cents:
> 
> * Soji does do beta releases
> * There is no point in changing the release cycle until we got really beta 
> testing
> 
> Also the very large organisations certainly can support Sympa in terms of 
> funding, manpower, testing changes etc ...
> 
> Regards
>         Racke
> 
> -- 
> Ecommerce and Linux consulting + Perl and web application programming.
> Debian and Sympa administration. Provisioning with Ansible.


-- 
株式会社 コンバージョン
ITソリューション部 システムソリューション1グループ 池田荘児
〒140-0014 東京都品川区大井1-49-15 アクセス大井町ビル4F
e-mail address@concealed  TEL 03-6429-2880
https://www.conversion.co.jp/