Developers of Sympa

[Marc Chantreux <address@concealed>]

hello people,

> Honestly, I think we have to decide whether we throw current code
> base away or not, before taking about bright future of development.
> 
> I believe this is the matter worth arising in hackathon.

Well ... at some point, i tried to be quiet because i really think the
people who actually produce code are the people who should drive the
community and i have to admit i don't know how to provide a patch to
the current codebase without rewriting complete modules, throwing another
one while yelling at the code. But i never change my mind since i started
to setup the 20th hackathon: I *ideally* think that

* sympa the way it runs today is nice but frustrating on many points
  because it could handle much more usage scenarii if some things
  were fixed in the design.
* the current codebase isn't appropriate to reason about what sympa
  should be to make it future proof, we should start from scratch but
  it means a lot of work. my great question was: how about the
  tunnel effect.
* still we have to maintain and provide patches for the running
  instances of sympa. so we need some maintainance release of sympa.
* the team in charge of this maintainance should have a very good
  knowledge of the current base and should be very protective: just
  accept patches to fix a know problem with a minimal amount of changes.

When i tried to get sympa out of the Renater, David wasn't an option and
the only name i known back then was Soji. So i proposed to make soji in
charge of the 6.2 branch (i had semantic versionning in mind so it was
clear to me that it was about patch level only).

Then everything goes an unexpected way for me and i learnt a lot from
this year:

* mostly, i now think we don't even agree about the future of sympa
  and there isn't even a consensus about it. i think it's because of the
  awesomeness of sympa: it makes so many things possible so it can
  evolve in many directions.
* "maintainance" became nothing i imagined: some refactoring started,
  features changed and removed CGI support in the middle of the patch
  level. i tried to stop it on the chan but racke and soji explained to
  me that we had to move on. I was trying to say we should increase
  the minor number instead of patch level ... but it doesn't happen.
  also: we're i think we're releasing much to fast but here again,
  it seems it wasn't the accepted point of view.
* i was wondering: is the sympa community able to release a complete
  rewrite of sympa in a reasonable amount of time: it is clear now
  we can't without a massive support of external manpower and i failed
  to get it for the moment. so if we rewrite from scratch, we will have
  a massive tunnel effect we can't afford.

what now ?

* only Renater could provide more manpower right now. We're trying to get it
  but for the moment
* i still believe the current basecode is a dead end and we should not
  spend any time on it in an ideal case.
* i now agree that involving the whole community into a rewrite from
  scratch isn't a good thing: we need more contributors/sponsors
  if we expect it to be succesful.
* sympa the way it is right now isn't suitable to make sponsoring
  happens.

more than ever, i think that we should

* work rely on CPAN to change the situation: removing a lot of codebase
  and refactoring sympa *outside of sympa* by providing generic tools
  because those tools have much more chance to be adopted and maintained
  by newcommers than sympa itself.
* make our codebase as sexy as possible for perl beginners because
  one of the potential source of contributors is the french research
  community (the one sympa was written for) and they have a very bad
  idea (mostly FUD, ignorance and unfair) about what perl is so if we
  want them to hack we have two choices:

  * rewrite sympa in another language. I really would like to see
    one of those nice modern langages that can compile (crystal,
    rust, haskell, the future guile 3.0, ...) to be used in
    sympa but it means "rewrite from scratch" -> tunnel effect -> ...
    so we can't
  * try to promote perl as well as we can and help people to jump in
    with a very pleasant experience (which mean take care of
    their background to make perl looks like what they know). My plan
    was to rely on Sympatic to provide a modern programming experience
    an the perl tooling (cpanm, dzil, ...) because i as far as i saw,
    the ruby, python, js, go, rustn crystal people
    (and most of perl developers) are used to those kind of stuff and
    expect them while using a new technology and this is and this is a
    point where perl is excellent at.

so yes ... i still have a lot of expectations about the future of sympa
but let's be realistic: i don't know how to make it real because we
lack of work hours and concensus. As i have no more valid plan to make
"sympa great again", this hackathon is very important to me because it's
time for those who have one to rise the flag and i'll try to follow it.

regards
marc