Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 10 Aug 2011 13:34:42 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] Monitoring iterative algorithms
Message-ID: <20110810113442.GZ2590@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: 
 <CAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=K4w@mail.gmail.com>
 <4E4049F2.3040109@gmail.com>
 <CAGRH7HpxeW8GkLkWRKnfTj8kL64E_2waJB0THuPvQbRT-PQELQ@mail.gmail.com>
 <4E40E199.3070006@gmail.com>
 <4E415667.2020609@free.fr>
 <20110809164146.GY2590@dusk.harfang.homelinux.org>
 <CACMPRi3cg9pBmthwQMdwa0puDREK--ZBRCjmN3aiVciBxtVjmg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CACMPRi3cg9pBmthwQMdwa0puDREK--ZBRCjmN3aiVciBxtVjmg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: hel 20001; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at hel
X-Virus-Status: Clean

Hello.

> I think you hit the nail on the head with the comment:
> 
> "... but also the time to
> experiment. Only the latter will be able to tell if the design is good.
> And this must take time so that all the potential pitfalls can be ..."
> 
> Maybe this is chumming the water with more flotsam and jetsam, but a lot of
> the issues that arise in working out the best design ultimately revert to
> trying out a bunch of deadends [design by monte carlo ;)] The discussion on
> the list [from my rather limited history] seems to try to foresee all
> possible drawbacks with a design. This inevitably devolves into heated
> discussion and diminishing progress.
> 
> Would it be possible to fork the trunk of the source tree to an
> "experimental branch"? Whether its monitoring the progress of ODE solvers,
> other solvers or any other feature extension, work could proceed on this
> experimental branch unmolested. There would be no concern about whether is
> this a 4.0 or 3.0 feature. The feature would be folded into trunk once it is
> ready (as evidenced by a vote of all concerned parties). Furthermore, all of
> us would have something very concrete to discuss. It would allow all
> interested parties to submit competing versions-instead of arguing over
> snippets of code. Phil has stressed to me that once an API change is made,
> that change is almost set in stone. An experimental branch would allow us to
> be more flexible and make mistakes without fear of supporting a garbage
> interface.

For very-limited functionality, this could be an option. The big drawback
is that, if it takes time to implement, the merge with the "official" branch
may not be trivial. [IIUC, Ted suggested that "git" was superior to "svn"
in making this less of a pain.]

For functionality that encompasses a large part of the library, or a design
change, or a policy change, it will be even more difficult, even if your
proposal fits the initial bill as discussed on the ML.
I've attempted one such experiment. You could search the archive for
"cal10n". [Another project by Ceki Gulcu. Oops ;-).] I was asked to create a
"sandbox" branch; I did all the proof-of-concept coding. In the end,
nobody[1] checked out that branch for actual testing and the proposal was
rejected because none of its merits could redeem the supposedly fundamental
flaw of being (optionally) based on an external library (although that had
been made very clear on the ML, also during a very long discussion).
So, for me, never again! And I wouldn't dare advise it to anyone.

Practically, given the low human resources (w.r.t the amount of code) in CM,
I think that evolving the code together on a single branch is better.

Nevertheless I totally agree with you, and I've said many times on this list,
that
 * we should not expect to solve all problems in one ultimate design
 * we should release more often
 * we should not stick to old ways

In my opinion, discussions should serve to solve real problems of a software
library: bugs, design inconsistencies, efficiency improvements (in that
order).


Regards,
Gilles

[1] Please correct me if I'm wrong, and I apologize if so.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org