On 2018-07-19 00:24, Volker Braun wrote:
Since Erik is clamoring for a more calendar-driven release schedule,
here is a quick A/B test:
A) Keep the current process of releasing approximately every 3 months,
longer if people insist on having their own pet tickets merged at the
last minute.
B) Ke
+1 to B.
B can be more flexible if only the next release day is announced (on
sage-release) when a new sage is released, and if the release day may be
delayed on the release manager's discretion.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
I don't think this is a known issue. I created
https://trac.sagemath.org/ticket/25879 to track it.
Thanks for reporting this :)
On Wednesday, July 18, 2018 at 3:59:06 PM UTC+2, srozensz wrote:
> Hello,
>
> I'm running Sage 8.2 and this is what I have observed:
>
> sage: R = Zp(3,type = 'fixed-m
About the point 2, I did some modifications to the surface_dynamics
package that allows it to be compiled on archlinux (there was some
trouble of include paths with Cython). In order to try the changes
just run
$ pip2 install git+https://gitlab.com/videlec/surface_dynamics --user
In the future (
No, I'm fine with either way. Personally, I think more flexibility is going
to be an advantage most of the time. Though I also see how strict rules
appeal to mathematicians. The same people that wish for a rigid schedule
now will complain later that they missed the merge window by a day ;-) Both
On Wed, Jul 18, 2018 at 3:24 PM, Volker Braun wrote:
> Since Erik is clamoring for a more calendar-driven release schedule, here is
> a quick A/B test:
>
> A) Keep the current process of releasing approximately every 3 months,
> longer if people insist on having their own pet tickets merged at the
Since Erik is clamoring for a more calendar-driven release schedule, here
is a quick A/B test:
A) Keep the current process of releasing approximately every 3 months,
longer if people insist on having their own pet tickets merged at the last
minute.
B) Keep a strict time table: Merge window is
On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote:
>
> As I wrote previously, I made this fix back in April,
> but tabled getting the fix directly into Sage since I thought it would
> be no big deal to make a Cysignals release and update Sage's
> dependency on it
By definition,
Le mercredi 18 juillet 2018 23:44:33 UTC+2, Volker Braun:
>
> I haven't looked at the diff set, but we did have regressions
> from minor cysignals changes before. Its just that signal handlers,
> due to their asynchronous nature and interactions with the OS,
> are notoriously hard to reason about
There is nothing particularly newsworthy about the buildbot setup, at the
end of the day it essentially just calls "make start" and "sage -t --all".
I don't think having more detail is going to be of any help in setting up a
buildbot worker. But I'll PM you the entire config if you want to see f
As one small data point I can say that I already upgraded cysignals in nixpkgs
(tested Linux, although it could technically be used on other platforms too). I
didn't run into any obvious issues.
I also think we should merge that upgrade for 8.3. Erik put in a lot of work to
make that platform s
On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote:
>
> All that said, your claim that this is a "high-risk" upgrade is also
> highly specious. This is upgrading Cysignals from 1.7.1 to 1.7.2 [1]
> which contains a couple bug fixes, the most significant of which (in
> terms of pat
On 2018-07-18 13:34, Erik Bray wrote:
This is again specious, and needlessly disparaging and antagonistic.
I don't believe if takes 2 weeks to run CI tests
Just replying on this point: the problem is that many things are not
caught by CI, especially things related to the build system and porta
Hello,
I'm running Sage 8.2 and this is what I have observed:
sage: R = Zp(3,type = 'fixed-mod', prec = 5)
sage: S. = R[]
sage: W. = R.extension(t^2-3)
sage: w.residue()
1
the output here should be 0.
The bug also appears with ZpCA(3,5) instead of Zp(3,type = 'fixed-mod',
prec = 5), but the ou
On Wed, Jul 18, 2018 at 12:13 AM Volker Braun wrote:
There's at least a few things I should say here.
> I do appreciate your hard work in making Cygwin work. But IMHO thats a rather
> high-risk upgrade with little reward. Nobody stops you from merging that
> ticket when building cygwin binarie
On Wed, Jul 18, 2018 at 12:22 AM Volker Braun wrote:
>
> The buildbot master config isn't public since it includes the worker
> passwords. Though I think the worst case means somebody can submit incorrect
> build results. Still, there wasn't much need to make the config public. If
> you want to
On Wednesday, July 18, 2018 at 5:46:35 AM UTC+2, Travis Scrimshaw wrote:
>
> unless you (Volker) can guarantee that the next full release will be fully
> ready by Monday morning Eastern US time. However, that is only because it
> would be more prudent for the SageDays.
>
Thats likely if we don't
17 matches
Mail list logo
