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 <dbros...@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-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