commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [RNG] Release of v1.0: Schedule update
Date Thu, 06 Oct 2016 17:36:11 GMT
On Thu, Oct 6, 2016 at 10:07 AM, Dave Brosius <> wrote:

> I'd vote for putting down the paint brushes temporarily and consider the
> bike shed done.
> Let's get 1.0 out, and then folks can work on 1.1 while getting feedback
> from users, etc.

But is the painting considered for 1.1 in risk of breaking BC? If yes, we
need to keep talking or accept that the next release would be a BC-breaking
2.0. Both are fine with me, we just need to agree on a road-map.


> --dave
> ---
> <br type="_moz" />
> On 2016-10-06 11:10, Gilles wrote:
>> On Wed, 5 Oct 2016 18:04:43 +0200, Emmanuel Bourg wrote:
>>> Le 5/10/2016 à 18:01, Gilles a écrit :
>>> There hasn't been any repository activity concerned
>>>> with the above reports or other such new features.
>>>> Were there unanticipated problems?
>>> Just lengthy (and not yet finished) discussions :)
>> Well, you started them.
>> And they were on issues[1] supposed to be left for after
>> 1.0; and the LCG could have been added to a 1.1 release
>> (had I known that those discussions would pop up).
>> I'm still working on
>>> the LCG.
>> OK, but I'd like to know where we stand in terms of schedule
>> (given that, with a very comfortable margin for review, the
>> intended functionality[2] could have been released at least
>> 3 weeks ago[3], if not much earlier[4]).
>> Hence, could you please be more specific?
>> From the above I could only infer that it could take at leat
>> another week (to run the stress tests and update the user
>> guide).
>> =====
>> Warning: rant follows; those who are not willing to help
>> clear the atmosphere of the Commons project[5] are welcome
>> to stop reading at this point. :-)
>> =====
>> Since, on the PMC-private list, I've been accused of personal
>> attack (which I deny[6] because the incriminated passages were
>> in fact a reminder that one could not actually search for
>> "consensus"[7][8] when not taking the other's POV into account),
>> I'm obliged to stress that silently breaking an agreement is
>> something which one can rightfully consider as an attack.
>> =====
>> Defusing statements follow (which you should be read before
>> dismissing the above as an overly sensitive reaction).
>> =====
>> I assume that the attack was not intentional; we work on a
>> best-effort basis.
>> However, because we are _all_ working on a best-effort basis,
>> "agreement" must mean something.
>> Too often, what seemed to be an agreement turned out to be
>> more akin to a decoy[9]; this is _my_ feeling, thus not an
>> attack on anyone!
>> Do I need to stress that such a feeling is not nice,
>> especially in a place where "community" spirit is so
>> touted?[10]
>> When everything goes smoothly and everybody is of the same
>> opinion, then it is easy to go by the "community over code"
>> mantra.  You obviously don't even need it.
>> When there is divergence, it takes a lot more than saying
>> the "c7s" word for it to transform into reality.[11]
>> I'd suggest that people make some introspection into what
>> "community over code" could mean so that it actually helps,
>> rather than hinders, cooperation.[12]  The obvious sense which
>> one could infer from the phrase may indeed not be the most
>> effective towards that (IMO) worthy goal.
>> Thanks for your attention,
>> Gilles
>> [1] Largely stemming from your misunderstanding of the intended
>>     scope of "Commons RNG".
>> [2] Which I assumed was trivially inferred from the decisions
>>     taken within Commons Math (namely "pure Java" and the like).
>> [3]
>> [4] A big part of that code has actually been available for
>>     review since last March (albeit within development branches
>>     of Commons Math), and the issues being dealt with takes back
>>     to December 2015 (more than 9 months ago).
>> [5] A state of affairs that has made people leave, whatever the
>>     (real or perceived) reason.
>> [6] The ML archive is rather full of attacks against me (having
>>     been depicted as dismissive, stubborn, a sloppy coder, down
>>     to plainly stupid).
>> [7] Only Stian made some constructive step by spelling out the
>>     pros and cons of "modules vs projects".
>>     Yet nobody else seems interested to take that as input and
>>     consider the _realistic_ scope of "Commons RNG" in order to
>>     reach a conclusion.
>> [8] More on this in that other thread...
>> [9] With the consequence that I had been lured in doing actual,
>>     often tedious, work (for the sake of consensus) even when I
>>     had deemed it useless; and turned out to be so, in many cases.
>>     You can thus guess that, over the years, I was less and less
>>     amenable to accept such "consensus" (whenever one-sided
>>     "bargain" would have been a more appropriate description).
>> [10] Nobody finds it surprising that, in foreign policy, such a
>>      behaviour can lead to war; so why would it be surprising
>>      that it can poison the atmosphere in other areas too?
>> [11] It takes at least figuring out why some code is as it is;
>>      some "code archeology" would have provided many answers
>>      without the need to bring, again, the issues to the ML.
>> [12] Cooperation is certainly not letting someone work for 9
>>      months, not answering any of his requests for comments, and
>>      after all the code has been designed alone, and shown to be
>>      consistent, robust and correct (through almost 100% coverage,
>>      consolidation of the existing unit tests, and passing the
>>      most stringent test suites), start criticizing it based on
>>      personal taste.
>>> Emmanuel Bourg
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

E-Mail: |
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition <>
Spring Batch in Action <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message