[RNG] Release of v1.0: Schedule update

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[RNG] Release of v1.0: Schedule update

Gilles Sadowski
Hello.


Two weeks ago, we informally agreed on a two-weeks delay
of the release:
   http://markmail.org/message/brhdpc5hwjebc2z3
   http://markmail.org/message/kpc2brclkr5fyzoo
   http://markmail.org/message/7fr3aulx4inpplnw
in order to accommodate additional RNG implementations:
   https://issues.apache.org/jira/browse/RNG-16
   https://issues.apache.org/jira/browse/RNG-17

There hasn't been any repository activity concerned
with the above reports or other such new features.

Were there unanticipated problems?

In any case, please update the status.


Thanks,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

Emmanuel Bourg-3
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 :) I'm still working on
the LCG.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

Emmanuel Bourg-3
Le 6/10/2016 à 17:10, Gilles a écrit :
> Well, you started them.

Look, you replied to my message with 100 lines of text, this happens
with each of your messages. Sorry but I can't keep up, my time is too
limited. Please be synthetic.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

Dave Brosius-2
In reply to this post by Gilles Sadowski
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.

--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: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

garydgregory
On Thu, Oct 6, 2016 at 10:07 AM, Dave Brosius <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

Emmanuel Bourg-3
Le 6/10/2016 à 19:36, Gary Gregory a écrit :

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

Or we publish now a beta release with its own GAV and Java package. I'd
support a 1.0-beta1 release with the classes in the
org.apache.commons.rng.beta1 package and org.apache.commons:rng-beta1
Maven groupId/artifactId.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

Dave Brosius
In reply to this post by garydgregory
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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

Jörg Schaible-5
Dave Brosius wrote:

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

+1

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

Eric Barnhill
On Fri, Oct 7, 2016 at 8:54 AM, Jörg Schaible <
[hidden email]> wrote:

> Dave Brosius wrote:
>
> > I'd just release it, and
> > get some momentum going.
>


+1
Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Release of v1.0: Schedule update

Gilles Sadowski
In reply to this post by garydgregory
On Thu, 6 Oct 2016 10:36:11 -0700, Gary Gregory wrote:

> On Thu, Oct 6, 2016 at 10:07 AM, Dave Brosius <[hidden email]>
> 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?

What would constitute such a risk?

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

Before we can agree on such a map, we'd have to agree on the
contents...
I'm sorry that, by not following the development, some might have
been led to believe that scope could be wider than has been made
explicit in commit ad95b158ce08883d5c0229dc88def3899d340539.

Gilles

>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]