commons-dev mailing list archives

i think people understand an early product having breaking changes. The
interface is 'small' enough that having to redo a small amount of change
by clients is not an issue here. Whatever you do, it's likely that you
will get feedback from clients that you don't expect, which probably
prompts you to want breaking changes anyway. I'd just release it, and
get some momentum going.
dave
On 10/06/2016 01:36 PM, Gary Gregory wrote:
> On Thu, Oct 6, 2016 at 10:07 AM, Dave Brosius <dbrosius@apache.org> 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.
>
> Gary
>
>> --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] http://markmail.org/message/ymt43f3ajqm25vkk
>>> [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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org