Re: [sage-release] Re: Sage 8.3.beta1 released

Thanks for the release. On Ubuntu 14.04 I get LOTS of test timeouts that I didn't get previously. It's possible though that the system is just uder heavy load, but even re-running the tests with --failed keeps giving me timeouts for some modules. So I'm concerned about a real performance

Re: [sage-release] Re: Release process

On Tue, May 15, 2018 at 3:11 PM, Jeroen Demeyer wrote: > On 2018-05-15 14:35, Erik Bray wrote: >> >> I'm not convinced that's a real problem. This is what I meant by "yes >> its contents may change and shift rapidly, but for a sophisticated >> developer who just wants to peek

Re: [sage-release] Re: Release process

The integration branch is going to have its history rewritten regularly. The issue is that unsuspecting developers might *base* their contribution on the integration branch (i.e. go to github and select the branch with the most recent commits), and then have it yanked out from under their feet

Re: [sage-release] Re: Release process

May I argue that we should aim at being able to use *UN*sophisticated developers (such as, well... myself) ? There is a *lot* of "maintenance" tasks in Sage that can use (relatively) ignorant people. For example, maintaining Sage ports of well-understood packages (such as Maxima or, in my

Re: [sage-release] Re: Release process

On 2018-05-15 15:40, Emmanuel Charpentier wrote: Therefore, I think that contributing to Sage should not *require* a sophisticated understanding of the finer points of git care and feeding... Of course not. I don't think that anybody here proposed that. -- You received this message because

Re: [sage-release] Re: Release process

More helpful would be the info which trac tickets in the integration branch cause these merge failures. While basing off the branch might be a no-no, adding some positively reviewed tickets as dependencies to a ticket does not break stuff, at least in my experience. I can discover these

Re: [sage-release] Re: Release process

On Sat, May 12, 2018 at 10:31 AM, Marc Mezzarobba wrote: > Jeroen Demeyer wrote: >> To be honest, I think it's not very meaningful to do that without >> consulting the release manager. I mean, you can write up all the >> documentation that you want; in the end, it's the

[sage-release] Re: Sage 8.3.beta1 released

FWIW : on Debian testing running on Core i7 + 16 GB RAM, same results as for 8.3.beta0, i. e. one transient and two permanent errors (the same as before) : -- sage -t --long src/sage/rings/padics/padic_lattice_element.py #

Re: [sage-release] Re: Release process

On 2018-05-15 14:35, Erik Bray wrote: I'm not convinced that's a real problem. This is what I meant by "yes its contents may change and shift rapidly, but for a sophisticated developer who just wants to peek in on the release process this is not a problem". I agree that it's not a problem for

[sage-release] Re: Sage 8.3.beta1 released

For me on OS X, I get the same failures as in earlier versions (which may be related somehow to my system). But if I then do "sage -i database_gap" and run tests again, I get failures in permgroup.py and features/gap.py. For example: sage -t --long src/sage/features/gap.py

Re: [sage-release] Re: Release process

2018-05-15 18:59 GMT+02:00 Volker Braun : > > If you want better merge conflict information: extend the > "git releasemgr merge " script (part of the > git-trac repo) to diagnose which ticket the conflict came > from. Then I'll be happy to include that info when setting >

[sage-release] Re: Sage 8.3.beta1 released

this is already fixed in https://trac.sagemath.org/ticket/25323 please review :-) On Tuesday, May 15, 2018 at 4:44:03 PM UTC+1, John H Palmieri wrote: > > For me on OS X, I get the same failures as in earlier versions (which may > be related somehow to my system). But if I then do "sage -i

Re: [sage-release] Re: Release process

If you want better merge conflict information: extend the "git releasemgr merge " script (part of the git-trac repo) to diagnose which ticket the conflict came from. Then I'll be happy to include that info when setting the ticket back... -- You received this message because you are subscribed

[sage-release] Re: Sage 8.3.beta1 released

On Ubuntu 16.04, the command `./sage -t -p --all --long --optional=sage,optional,external` finishes with: -- sage -t --long src/sage/coding/code_constructions.py # 1 doctest failed

Re: [sage-release] Sage 8.3.beta0 released

> On May 9, 2018, at 11:44 , Volker Braun wrote: > > As always, you can get the latest beta version from the "develop" git branch. > Alternatively, the self-contained source tarball is at > http://www.sagemath.org/download-latest.html Built from a fresh clone/update of

Re: [sage-release] Sage 8.3.beta1 released

> On May 14, 2018, at 11:10 , Volker Braun wrote: > > As always, you can get the latest beta version from the "develop" git branch. > Alternatively, the self-contained source tarball is at > http://www.sagemath.org/download-latest.html Built from a fresh clone/update

[sage-release] Re: Sage 8.3.beta1 released

On Tuesday, May 15, 2018 at 4:44:03 PM UTC+1, John H Palmieri wrote: > > For me on OS X, I get the same failures as in earlier versions (which may > be related somehow to my system). But if I then do "sage -i database_gap" > and run tests again, I get failures in permgroup.py and

Re: [sage-release] Sage 8.3.beta0 released

On Tuesday, May 15, 2018 at 9:34:55 PM UTC+1, Justin C. Walker wrote: > > > > On May 9, 2018, at 11:44 , Volker Braun > wrote: > > > > As always, you can get the latest beta version from the "develop" git > branch. Alternatively, the self-contained source tarball is at

Re: [sage-release] Sage 8.3.beta0 released

> On May 15, 2018, at 17:07 , Dima Pasechnik wrote: > > > > On Tuesday, May 15, 2018 at 9:34:55 PM UTC+1, Justin C. Walker wrote: > > > On May 9, 2018, at 11:44 , Volker Braun wrote: > > > > As always, you can get the latest beta version from the

[sage-release] Re: Sage 8.3.beta1 released

Under macOS 10.10.5, after downloading the cysignals patch https://github.com/sagemath/cysignals /commit/daef81e2fc111378ccc58b3f572eb18c70753a30.patch into build/pkgs/cysignals/patches both the build+docbuild of Python2-based Sage and the build+nodocbuild of Python3-based Sage were