> Not really, you did explicitly ask to postpone a Sage release. I'm against
> that. I did not comment on the stopgap.
I did, and only because I thought others wanted it. I do not mind
myself, and I have no objection to a release tomorrow if the stopgap
is included.
Nathann
--
You received this
On 2015-10-02 17:17, Nathann Cohen wrote:
I merely ask for this
dangerous bug to trigger a stopgap warning.
Not really, you did explicitly ask to postpone a Sage release. I'm
against that. I did not comment on the stopgap.
--
You received this message because you are subscribed to the Google
> Why that? If you only want to release Sage when there are no known bugs, we
> will never release Sage again.
I did not ask for all bugs to be solved. I merely ask for this
dangerous bug to trigger a stopgap warning. This is easy to do.
Other people here seem more comfortable with the idea of ha
On 2015-10-02 08:48, Nathann Cohen wrote:
Couldn't we see with Volker if we
cannot have a couple of betas again and then release the next stable
version next month or so?
Why that? If you only want to release Sage when there are no known bugs,
we will never release Sage again.
Especially given
>
> In the real world "needing more time" is a perfectly normal reason to
> downgrade blockers. Look at any big project, e.g.
> http://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
>
You are right, and "fixing all hash functions" is not a blocker, as it is
obviously a lot of work.
The sto
In the real world "needing more time" is a perfectly normal reason to
downgrade blockers. Look at any big project,
e.g. http://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
On Friday, October 2, 2015 at 10:50:52 AM UTC+2, Nathann Cohen wrote:
>
> > That was exactly William's proposition, ex
> That was exactly William's proposition, except that it will be called
> 6.10.betaN instead of 6.9.beta(N+8).
This 'except', my dear Volker, is precisely the reason why we are
having this gentle chat here.
Nathann
--
You received this message because you are subscribed to the Google Groups
"s
On Friday, October 2, 2015 at 8:48:03 AM UTC+2, Nathann Cohen wrote:
>
> version soon? Couldn't we see with Volker if we cannot have a couple of
> betas again and then release the next stable version next month or so?
>
That was exactly William's proposition, except that it will be called
6.10.b
Small update to Vincent's ranking: #19321 now has a positive review.
Nathann
On 2 October 2015 at 08:48, Nathann Cohen wrote:
> Let me add something: is there really *anything* that forces us to release
> the next stable version soon? Couldn't we see with Volker if we cannot have
> a couple of
Let me add something: is there really *anything* that forces us to release
the next stable version soon? Couldn't we see with Volker if we cannot have
a couple of betas again and then release the next stable version next month
or so?
We seem in a hurry to do things, but we have control of the dead
Yoo,
About your order of preferences:
> 1) fix and merge #19016 before the stable
+1, but given the amount of work I do not see it happen quickly enough.
> 2) merge #19321 and #19331 before the stable
Big +1 to that. With [new individual hash functions] added to [a default
hash to
Hello,
Let me try to summarize:
1) The hash of Element is definitely wrong in *some* situations. For the
computation of Cayely graphs of finitely presented groups. Or if an
element is renamed as in
sage: class E(Element): pass
sage: e = E(Parent())
sage: e.rename('toto')
sage: hash(e)
231405
On Thu, Oct 1, 2015 at 12:35 PM, Nathann Cohen wrote:
>> This message seems like flamebait [1],
>
> That's because I took your proposal of hiding bugs under the carpet
> and *not tell the users* as an insult against scientific honesty. The
> kind of honesty that I would expect if I were a user of
> This message seems like flamebait [1],
That's because I took your proposal of hiding bugs under the carpet
and *not tell the users* as an insult against scientific honesty. The
kind of honesty that I would expect if I were a user of Sage.
In the future, I agree that it would be more proper that
On Thu, Oct 1, 2015 at 11:27 AM, Nathann Cohen wrote:
>[...]
> Professionals. That's a joke.
This message seems like flamebait [1], hence probably does not belong
on this list, and belongs on sage-flame [2] instead. I think it is
best if people direct any responses to sage-flame [2] rather than
I will always be amazed at how lightly you take that the code we develop
can cause serious harm to our user's computations, as well as their trust
in this software.
Look how easy it is for you all to say that we will release this "stable"
version of Sage with a known dangerous bug inside, witho
On Thu, Oct 1, 2015 at 8:07 AM, Travis Scrimshaw wrote:
>
>>>
>>> Thanks Volker for writing an e-mail before the clash.
>>>
>>> To my mind, it is a complete nonsense to merge this stopgap in a rc0. We
>>> would have time to fix the hash issues along a development cycle starting
>>> from an early b
>
>> Thanks Volker for writing an e-mail before the clash.
>>
>> To my mind, it is a complete nonsense to merge this stopgap in a rc0. We
>> would have time to fix the hash issues along a development cycle starting
>> from an early beta. And most of them if not all should be fixed before any
>
On Thursday, October 1, 2015, Vincent Delecroix <20100.delecr...@gmail.com>
wrote:
> Hello,
>
> Thanks Volker for writing an e-mail before the clash.
>
> To my mind, it is a complete nonsense to merge this stopgap in a rc0. We
> would have time to fix the hash issues along a development cycle star
Hello,
Thanks Volker for writing an e-mail before the clash.
To my mind, it is a complete nonsense to merge this stopgap in a rc0. We
would have time to fix the hash issues along a development cycle
starting from an early beta. And most of them if not all should be fixed
before any stable rel
Just as a PSA you better get used to this warning:
sage: G = FreeGroup(2)
sage: x,y = G.gens()
sage: H = G / [x**2, y**2]
/opt/sage/src/bin/sage-ipython:1:
The __hash__ method of Element is broken. Beware of any
funct
21 matches
Mail list logo