Le 14/05/2011 17:54, Phil Steitz a écrit :
On 5/14/11 8:31 AM, Dimitri Pourbaix wrote:
Phil,

Sorry, Dmitri, but that is not an acceptable "veto" from the ASF
perspective.  When you say "-1" to a technical (code-related)
change, you need to provide a technical reason to support your
veto.  Do you have technical problems with the code being proposed
for inclusion?

In a strict democracy, there is nothing such as a veto!  I am not
'vetoing' anything (and do not want to), I am only expressing my
opinion, as requested, to Luc's wish to add this component to math.

OK.  As a committer, you do have the ability to veto any code
change.  When you do that, you are expected to provide a technical
reason.

Can you explain a little more why you consider it a bad idea to
include the [bsp] code in [math]?   I understand (and share) your
frustration on getting some aspects of the 3.0 API settled; but I
think we are making progress and I don't see adding the bsp code as
really making a difference there.  It does not look to me like it
will be hard to adapt the exceptions management or other aspects of
the [bsp] API to whatever we settle on for [math] 3.0, and without
speaking for him, I assume that Luc is willing to do whatever
repackaging or other work is necessary to bring it in.

The repackaging was almost already done when the component was put in sandbox. Of course I will adapt strictly to the current [math] API, i.e. I will use MathRuntimeException as the base class for BSPException.

Dimitri, I don't think you are really speaking about exception repackaging, you pointed it out only has an example of endless discussions, among others. I share your disappointment about this and would hope we converge more quickly. It seemed we did finally converge here, so the discussions where finally not endless. One of the reasons we had a hard time getting a consensus is that exceptions are used everywhere, so everybody is concerned but at the same time it is clearly not the core of the library, they are only a tool. This is a clear syndrom of bikeshedding (sess <http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality>). We are out of it now.

I don't expect BSP or any other new specific feature added to [math] would drastically impair our capability to publish new versions. Specific features are mostly independent of each others and don't trigger much buzz. After all, the other part of Parkinson's law of triviality is that important stuff is settled more quickly than trivial stuff. The only other long discussion I expect in the near future is linear algebra because it is also used in many places and in many different contexts.

Does this explanation help ? Would you consider changing your -1 into a -0 ?

best regards,
Luc


Phil

Regards,
  Dim.
----------------------------------------------------------------------------

Dimitri Pourbaix                         *
Institut d'Astronomie et d'Astrophysique *      Don't worry, be happy
CP 226, office 2.N4.211, building NO     *         and CARPE DIEM.
Universite Libre de Bruxelles            *
Boulevard du Triomphe                    *      Tel : +32-2-650.35.71
  B-1050 Bruxelles                        *      Fax : +32-2-650.42.26
http://sb9.astro.ulb.ac.be/~pourbaix     *
mailto:pourb...@astro.ulb.ac.be

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




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



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

Reply via email to