Developers of Sympa

[IKEDA Soji <address@concealed>]

Guillaume,

On Tue, 22 Oct 2013 16:04:14 +0200
Guillaume Rousse <address@concealed> wrote:

> Le 22/10/2013 14:40, IKEDA Soji a écrit :
> >>> 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?
> Sure, and that's what I tried to do by introducing unit tests in 
> sympa-cleanup branch, before introducing code refactoring.

Unit test is essintial element of XP or similar practices.
I suppose this is one of important things we have to adopt.

> > 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.
> File relocation, subversion metadata harmonisation, file content 
> correction, headers consistency enforcement (once content decided): one hour
> 
> Fixing code layout (indentation, spacing, etc): one hour.
> 
> Transfering all Sympa code to a Sympa:: namespace: one hour.
> 
> Turning all methods and functions calls to fully-qualified syntax: one hour.
> 
> Sorting import statement, dropping useless ones, adding needed ones: one 
> hour.
> 
> Basically, all of this can be achieved in one day work.

It's difficult for me.

# Indeed, if "one day" means "twenty-four man-hours", you are right.
# We are all volunteering.

> What takes times, tough, is to gradually refactor functions and methods 
> prototypes, and split modules, to reduce cross dependencies, and reach a 
> testable state. One week, eventually, but definitively not one month. 
> And even less, if everyone concurs in the same direction, instead of 
> following its own agenda.
> 
> > 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).
> Thanks for your suggestion, I already read it, quite a long time ago. 

Then, the story is easy.

Would you please make the rule of naming convention for conding of
Sympa, according to practices the author presents in Chapter 2?

Frankly, your arguements about naming convention seems inconsistent,
subjective, inconprehensive, ...for me.

The author recommends usage of Backus-Naur form to define naming
convention.  I feel this fifty-years-old notation["] is useful
to devide syntaxes and semantics: This can eliminate arguements
about semantics such as "I think such a class is not required".

Either someone think a particular class required or not, if it is
not named, it cannot be discussed at all.

As a result, opposer(s) will always win: It will, I dare to say,
introduce Absolute Monarchy into discussion.

> But this is still a book, not a bible. And achieving conformity is not 

I'm not a Christian.  I cannot understand your metaphor.
Conway's book is not the canon.  It is just a list of practices.

Would you please make it?

<<snip>>

Regards,

--- Soji

[*] Well, fifty years ago, the revised report on ALGOL 60 was
published.

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