Skip to Content.
Sympa Menu

devel - [sympa-developpers] Coming versions

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: IKEDA Soji <address@concealed>
  • To: address@concealed
  • Subject: [sympa-developpers] Coming versions
  • Date: Tue, 22 Oct 2013 21:40:10 +0900

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. I'm grad to certain your constant
motivation.

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!

> > 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.


> 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.


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).


Forgive my impolite words and idle talk,

--- 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! :-/

--
株式会社 コンバージョン セキュリティ&OSSソリューション部 池田荘児
〒231-0004 神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed TEL 045-640-3550
http://www.conversion.co.jp/



Archive powered by MHonArc 2.6.19+.

Top of Page