Developers of Sympa

[David Verdin <address@concealed>]

Dear all,

Le 22/10/13 14:40, IKEDA Soji a écrit :

Hi,

At first, David, thank you for your tenacious work to continue this
project.

Frankly say, in these days I was worrying that Sympa project no
longer release new versions.

Oh it will. We need these new versions. We need all the features i mentionned (i18ned email adresses for example, and SaaS). so we will issue new version, whatever it takes.

I'm grad to certain your constant
motivation.

My motivation never decreases. Sympa is the best development project I have ever worked on.
What decreases sometimes is the time I can spend on the project. Every now and then, I need to concentrate on other tasks. ;-)

On Tue, 22 Oct 2013 10:07:10 +0200
Guillaume Rousse <address@concealed> wrote:

Le 22/10/2013 09:51, David Verdin a écrit :

Dear Soji,

I agree with you: We need to keep proper legal information and we'll
take your template. Thsi template works, is a good short term solution
and we'll keep further discussion about licence and discmlaimers for
when we are not more than one year late to issue a new Sympa version.

Great!

Good. We'll apply the template starting from the next release.

As I'm talking about it: we need to issue a Sympa version soon. our
community will start to wonder why no Sympa version is issued. They can
start to think that the project is dead, as nothing new was issued since
more than one year.

What we want here:

  * Have an alpha in production in november
  * Issue a beta in december.
  * Have a stable version in the beginning of 2014 (probably February).

I'll take the latest discussions in the developpepers mailing list,
propose a decision, and we'll stick with it for the 7.0.

We need to issue a Sympa version, or the project will be in a very bad
shape.

That seems indeed a good idea, but I think it's suicidal to consider the 
current content of sympa-cleanup branch as a viable solution to produce 
even an alpha release: the code doesn't even compile, and is a ugly mix 
between one year of parallel development.

I agree.  Additionally, I have wished that the development style of
Sympa would gradually approach to "continuous integration" practice:

By relatively short periods (e.g. several months), repetitive
regular releases will be issued.  No matter what each release is,
it may always contain some improvements or fixes.  That's good
enough, isn't that?

To reach such stage, we will have to overcome a number of problems.
Although, I would like you to note my ambition.

Great!
All the work made on test by Guillaume will certainly ease this process.
Once I have fixed the missing dependencies on our Jenkins server, continuous integration will be a reality.
Actually, issuing new versions regularly is the normal functionning of the Sympa project. Had I not obsessively tried to integrate the desastrous "database spool" contribution, we would have issued a Sympa 6.2 one year ago.
For this, I apologize.

For me, the viable solution would be to use as base either:
a) sympa-6.2 branch, for new features
b) sympa-cleanup before the merge, for code readability

And once one branch chosen as base, eventually replay some of the 
changes introduced in the other progressively, using the minimal test 
suite to catch regression after each commit.

Given most of my initial changes were purely syntactic ones, easy to 
replay mechanically, and than I never even attempted to actually run my 
code outside of unit tests, I really think we should use sympa-6.2 as base.

As I said, I had privately replayed your changes.  In so far as
syntactic changes and relocations, it may be relatively easy: It may
be done in a month.

We don't have to.
We have a working 6.2 version on our production server. It contains most of the new features except the database cache.
The main addition of what is in the sympa-cleanup branch is the configuration cache and all the refactoring we did over the last year.
So if you (Soji) agree with the proposal to issue the pre-"spool database works" 6.2 version, and you confirm that it will please your management enough, we'll do it.

However, I regret to say that we might not commit anything new to
repository, while we had not had common perspective of development,
coding and modularization.

Conway's “Perl Best Practices”(«De l'art de programmer en Perl»)
suggested by David seems ideal basis of our mutual understanding.
IMHO it is rather the book on psychology than programming: It
accurately points out many psychological traps all programmers are
fallable [*].

Conversely, if you had not finished reading this book, even if we
agreed on all other issues, we have not made consensus, Guillaume.

Please inform us when you have finished reading (or if you have not
begun, when you began, too).

I think Guillaume has read this book as he was one of those who advised me to read it.
I agree on the point in which you state that you and Guillaume don't have the same views on development. but I don't think that's unsolvable.
From my point of view, all the solutions you both propose look good: they consist of working code that does what it is intended to do.
If we stick to conway's proposals, we'll have a lot of problems solved, even if they are not perfect.

Forgive my impolite words and idle talk,

I didn't read anything impolite. You just said what you had in mind and gave us the shake we needed to move on and make the right decisions.
All in all

--- Soji


[*] Note that we must not adhere all 256 recommendations in this
book: Some of them are slightly indifferent; a few of them are
exactly not applicable to Sympa; many of remainder may be difficult
to obey in a few weeks.  I suppose what we need at present is common
perspective.
Nevertheless, each recommendation is suggestive --- In my laughter,
rereading it last month, I found that the "_gestalt_ psychodynamic
ramifications of the class on the collective developer consciousness"
(p. 344 in English ed.) had also occurred in this list! :-/

--
A bug in Sympa? Quick! To the bug tracker!

David Verdin Études et projets applicatifs
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

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