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

[Justin C. Walker]

> 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 "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 the develop branch on macOS 10.11.6 
> (Quad-core Core i7) w/o problems,.  One problem in testing (‘ptestlong’): 
> 
> sage -t --warn-long 89.1 src/sage/rings/complex_arb.pyx  # 1 dockets failed 
> 
> When run by hand, I got the same failure.  Log from the single run attached. 

> Looks OK, just a different order of data in the output, no?

Almost - there’s a slight difference in wording, it appears.  Also, is the 
doctest apparatus supposed to detect order differences?

Justin

--
Justin C. Walker
Curmudgeon-at-large
Director
Institute for the Absorption of Federal Funds

186,000 Miles per Second
Not just a good idea:
  it's the law!


-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

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

[Dima Pasechnik]

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 
> http://www.sagemath.org/download-latest.html 
>
> Built from a fresh clone/update of the develop branch on macOS 10.11.6 
> (Quad-core Core i7) w/o problems,.  One problem in testing (‘ptestlong’): 
>
> sage -t --warn-long 89.1 src/sage/rings/complex_arb.pyx  # 1 dockets 
> failed 
>
> When run by hand, I got the same failure.  Log from the single run 
> attached. 
>
> Looks OK, just a different order of data in the output, no?

> Justin
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

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

[Samuel Lelievre]

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 successful. I have not run the tests.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

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

[Justin C. Walker]

> 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 of the develop branch on macOS 10.11.6 
(Quad-core Core i7) w/o problems,.  As for B0, there was one problem in testing 
(‘ptestlong’):

sage -t --warn-long 89.1 src/sage/rings/complex_arb.pyx  # 1 dockets failed

Again, running stand-alone showed the same failure as in B0.

Justin

--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
---
Like the ski resort full of girls hunting for husbands
and husbands hunting for girls, the situation is not
as symmetrical as it might seem.
  - Alan MacKay
--

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

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

[Justin C. Walker]

> 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 the develop branch on macOS 10.11.6 
(Quad-core Core i7) w/o problems,.  One problem in testing (‘ptestlong’):

sage -t --warn-long 89.1 src/sage/rings/complex_arb.pyx  # 1 dockets failed

When run by hand, I got the same failure.  Log from the single run attached.

Justin

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.


complex_arb.log
Description: Binary data


--
Justin C. Walker, Curmudgeon-At-Large
Director
Institute for the Enhancement of the Director's Income

"Weaseling out of things is what separates us from the animals.
 Well, except the weasel."
  - Homer J Simpson



-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

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

[Sébastien Labbé]

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
--
Total time for all tests: 1821.3 seconds
cpu time: 11639.5 seconds
cumulative wall time: 14059.4 seconds
External software detected for doctesting: gurobi,latex
Traceback (most recent call last):
  File "/home/slabbe/GitBox/sage/src/bin/sage-runtests", line 127, in 

err = DC.run()
  File 
"/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/doctest/control.py",
 
line 1176, in run
+ ','.join(available_software.seen()))
  File 
"/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/doctest/control.py",
 
line 583, in log
self.logger.write(s + end)
  File 
"/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/doctest/control.py",
 
line 250, in write
f.write(x)
ValueError: I/O operation on closed file


The code_construction error is copied below (I can not reproduce it) :



sage -t --long src/sage/coding/code_constructions.py
**
File "src/sage/coding/code_constructions.py", line 624, in 
sage.coding.code_constructions.QuadraticResidueCodeOddPair
Failed example:
codes.QuadraticResidueCodeOddPair(17, GF(13))
Exception raised:
Traceback (most recent call last):
  File 
"/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py",
 
line 562, in _run
self.compile_and_execute(example, compiler, test.globs)
  File 
"/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py",
 
line 972, in compile_and_execute
exec(compiled, globs)
  File "", line 1, in 

codes.QuadraticResidueCodeOddPair(Integer(17), GF(Integer(13)))
  File 
"/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/coding/code_constructions.py",
 
line 666, in Quadratic
ResidueCodeOddPair
return DuadicCodeOddPair(F,Q,N)
  File 
"/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/coding/code_constructions.py",
 
line 425, in DuadicCod
eOddPair
gg1 = P2(coeffs1)
  File "sage/structure/parent.pyx", line 920, in 
sage.structure.parent.Parent.__call__ (build/cythonized/sage/structure/paren
t.c:9734)
return mor._call_(x)
  File "sage/structure/coerce_maps.pyx", line 145, in 
sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (build/cytho
nized/sage/structure/coerce_maps.c:4555)
raise
  File "sage/structure/coerce_maps.pyx", line 140, in 
sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (build/cytho
nized/sage/structure/coerce_maps.c:4423)
return C._element_constructor(x)
  File 
"/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_ring.py",
 
line 404, in _e
lement_constructor_
return C(self, x, check=check, is_gen=False, construct=construct)
  File "sage/rings/polynomial/polynomial_zmod_flint.pyx", line 100, in 
sage.rings.polynomial.polynomial_zmod_flint.Polynomial
_zmod_flint.__init__ 
(build/cythonized/sage/rings/polynomial/polynomial_zmod_flint.cpp:14358)
lst = [k(i) for i in x]
  File "sage/structure/parent.pyx", line 920, in 
sage.structure.parent.Parent.__call__ (build/cythonized/sage/structure/paren
t.c:9734)
return mor._call_(x)
  File "sage/rings/finite_rings/hom_prime_finite_field.pyx", line 46, 
in sage.rings.finite_rings.hom_prime_finite_field.Secti
onFiniteFieldHomomorphism_prime._call_ 
(build/cythonized/sage/rings/finite_rings/hom_prime_finite_field.c:3457)
raise ValueError("%s is not in the image of %s" % (x, 
self._inverse))
ValueError: 3*z^3 + 2*z^2 + 8*z + 1 is not in the image of (map 
internal to coercion system -- copy before use)
Ring morphism:
  From: Finite Field of size 13
  To:   Finite Field in z of size 13^4
**
1 item had failures:
   1 of  13 in sage.coding.code_constructions.QuadraticResidueCodeOddPair
[146 tests, 1 failure, 2.56 s]

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Samuel Lelièvre]

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
> the ticket back...

I opened an issue for that:

https://github.com/sagemath/git-trac-command/issues/29

If someone can provide this enhancement, that would be great!

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[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 the ticket back...

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

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

[Dima Pasechnik]

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 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
> **
> File "src/sage/features/gap.py", line 41, in 
> sage.features.gap.GapPackage._is_present
> Failed example:
> GapPackage("prim", spkg="database_gap").is_present()  # optional: 
> database_gap
> Expected:
> FeatureTestResult('GAP package prim', True)
> Got:
> FeatureTestResult('GAP package prim', False)
> **
> 1 item had failures:
>1 of   3 in sage.features.gap.GapPackage._is_present
> [12 tests, 1 failure, 5.81 s]
> --
> sage -t --long src/sage/features/gap.py  # 1 doctest failed
> --
>
> Emmanuel, is this what you are seeing?
>
> -- 
> John
>
>
>
> On Tuesday, May 15, 2018 at 5:46:00 AM UTC-7, Emmanuel Charpentier wrote:
>>
>> 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  # Timed out
>> sage -t --long src/sage/groups/perm_gps/permgroup.py  # 1 doctest failed
>> sage -t --long src/sage/features/gap.py  # 1 doctest failed
>> --
>>
>> HTH,
>>
>> --
>> Emmanuel Charpentier
>>
>>
>> Le lundi 14 mai 2018 20:10:54 UTC+2, Volker Braun a écrit :
>>>
>>> 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
>>>
>>> 6fc1e20c66 (tag: 8.3.beta1) Updated SageMath version to 8.3.beta1
>>> 8c327b9901 Trac #25258: Gurobi breaks lots of doctests in make ptestlong
>>> 47a7327e12 Trac #25248: py3: fix sage.parallel.map_reduce
>>> 7feb4d298c Trac #25244: LatticePoset: Add is_interval_dismantlable
>>> 3e6075d57b Trac #25236: Deprecate various functions from old coercion 
>>> model
>>> c4b415fa9f Trac #25235: q-Stirling numbers of the second kind
>>> 2c90815686 Trac #25224: Mismatch in the definition of dilog() between 
>>> fricas and sympy
>>> 3ab97b15d3 Trac #25223: Cleaning of the usage of BFS
>>> bf0beabf6a Trac #25220: fix definite fricas integration
>>> 88e1ed6d0e Trac #25216: py3: fix bytes handling bugs in sage.plot.animate
>>> deae517486 Trac #25211: code should not depend ordering of codegrees
>>> eb2f271af2 Trac #25203: Speed up FiniteField.zeta()
>>> 22b8be8a05 Trac #25201: Use super() in MatrixSpace.__getitem__
>>> 9a7f40d097 Trac #25200: Incorrect long element for signed permutations
>>> eba77d3f14 Trac #25195: py3: fix segfault in element wrapper on Python 3
>>> f5527d2184 Trac #25192: primitivity test for integral matrices
>>> b3b4f75048 Trac #25186: Use ZZ.random_element for random_prime
>>> 7e6c6ab9e5 Trac #25182: coherent output type for polynomial.degree()
>>> 6aafae Trac #25174: conversion of I to fricas is wrong
>>> 6a34919efb Trac #25169: py3: fixing print in sage-starts script
>>> 80d4a17edc Trac #25161: Sphinx build hangs when a BaseException occurs
>>> 6f130ae999 Trac #25146: Cleanup of AbstractPartitionDiagram
>>> 41c9fffbe1 Trac #24966: package primecount 4.3
>>> 72980a10a1 Trac #24890: Tensor product of lattices
>>> 951fa49129 Trac #24460: py3: fixes to sage.libs.gap
>>> e5af4884cc Trac #15508: Implement Fock space
>>> 4756f04cbe Trac #25335: Missing imports in 
>>> src/sage/geometry/polyhedron/base.py
>>> faad356119 Trac #25133: Implement WQSym
>>> b593af3371 Trac #25132: Define the class of SuperPartitions
>>> c1a36a02ee Trac #25131: FQSym: add G basis
>>> ad72cec5b8 Trac #25128: Have py_scalar_to_element convert gmpy2 numbers
>>> 81f7d7a341 Trac #25121: fix edge color format in graphviz_string
>>> 8821bb1454 Trac #25120: dot2tex edge coloring is broken
>>> 80fa1be913 Trac #25117: some pyflakes cleanup for unused variables
>>> fd8c5d4676 Trac #25112: perl_term_readline_gnu: Upgrade to 1.35 and 
>>> patch away ncurses problem
>>> bf6cbafbed Trac #25109: Upgrade cmake to 3.11.0
>>> 07ce7c88bf Trac #25105: ell_number_field.py takes a long time to test
>>> bb996e69ec Trac #25098: Fix LaTeX usage in Rings documentation
>>> eecf07e8c7 Trac #25095: polygon3d ignores the "alpha" (and equivalent 
>>> "opacity") argument
>>> 15b5aa2b60 Trac #25081: The polar of a polyhedron should carry the 
>>> backend used.
>>> 

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

[Dima Pasechnik]

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 features/gap.py. 
> For example:
>
> sage -t --long src/sage/features/gap.py
> **
> File "src/sage/features/gap.py", line 41, in 
> sage.features.gap.GapPackage._is_present
> Failed example:
> GapPackage("prim", spkg="database_gap").is_present()  # optional: 
> database_gap
> Expected:
> FeatureTestResult('GAP package prim', True)
> Got:
> FeatureTestResult('GAP package prim', False)
> **
> 1 item had failures:
>1 of   3 in sage.features.gap.GapPackage._is_present
> [12 tests, 1 failure, 5.81 s]
> --
> sage -t --long src/sage/features/gap.py  # 1 doctest failed
> --
>
> Emmanuel, is this what you are seeing?
>
> -- 
> John
>
>
>
> On Tuesday, May 15, 2018 at 5:46:00 AM UTC-7, Emmanuel Charpentier wrote:
>>
>> 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  # Timed out
>> sage -t --long src/sage/groups/perm_gps/permgroup.py  # 1 doctest failed
>> sage -t --long src/sage/features/gap.py  # 1 doctest failed
>> --
>>
>> HTH,
>>
>> --
>> Emmanuel Charpentier
>>
>>
>> Le lundi 14 mai 2018 20:10:54 UTC+2, Volker Braun a écrit :
>>>
>>> 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
>>>
>>> 6fc1e20c66 (tag: 8.3.beta1) Updated SageMath version to 8.3.beta1
>>> 8c327b9901 Trac #25258: Gurobi breaks lots of doctests in make ptestlong
>>> 47a7327e12 Trac #25248: py3: fix sage.parallel.map_reduce
>>> 7feb4d298c Trac #25244: LatticePoset: Add is_interval_dismantlable
>>> 3e6075d57b Trac #25236: Deprecate various functions from old coercion 
>>> model
>>> c4b415fa9f Trac #25235: q-Stirling numbers of the second kind
>>> 2c90815686 Trac #25224: Mismatch in the definition of dilog() between 
>>> fricas and sympy
>>> 3ab97b15d3 Trac #25223: Cleaning of the usage of BFS
>>> bf0beabf6a Trac #25220: fix definite fricas integration
>>> 88e1ed6d0e Trac #25216: py3: fix bytes handling bugs in sage.plot.animate
>>> deae517486 Trac #25211: code should not depend ordering of codegrees
>>> eb2f271af2 Trac #25203: Speed up FiniteField.zeta()
>>> 22b8be8a05 Trac #25201: Use super() in MatrixSpace.__getitem__
>>> 9a7f40d097 Trac #25200: Incorrect long element for signed permutations
>>> eba77d3f14 Trac #25195: py3: fix segfault in element wrapper on Python 3
>>> f5527d2184 Trac #25192: primitivity test for integral matrices
>>> b3b4f75048 Trac #25186: Use ZZ.random_element for random_prime
>>> 7e6c6ab9e5 Trac #25182: coherent output type for polynomial.degree()
>>> 6aafae Trac #25174: conversion of I to fricas is wrong
>>> 6a34919efb Trac #25169: py3: fixing print in sage-starts script
>>> 80d4a17edc Trac #25161: Sphinx build hangs when a BaseException occurs
>>> 6f130ae999 Trac #25146: Cleanup of AbstractPartitionDiagram
>>> 41c9fffbe1 Trac #24966: package primecount 4.3
>>> 72980a10a1 Trac #24890: Tensor product of lattices
>>> 951fa49129 Trac #24460: py3: fixes to sage.libs.gap
>>> e5af4884cc Trac #15508: Implement Fock space
>>> 4756f04cbe Trac #25335: Missing imports in 
>>> src/sage/geometry/polyhedron/base.py
>>> faad356119 Trac #25133: Implement WQSym
>>> b593af3371 Trac #25132: Define the class of SuperPartitions
>>> c1a36a02ee Trac #25131: FQSym: add G basis
>>> ad72cec5b8 Trac #25128: Have py_scalar_to_element convert gmpy2 numbers
>>> 81f7d7a341 Trac #25121: fix edge color format in graphviz_string
>>> 8821bb1454 Trac #25120: dot2tex edge coloring is broken
>>> 80fa1be913 Trac #25117: some pyflakes cleanup for unused variables
>>> fd8c5d4676 Trac #25112: perl_term_readline_gnu: Upgrade to 1.35 and 
>>> patch away ncurses problem
>>> bf6cbafbed Trac #25109: Upgrade cmake to 3.11.0
>>> 07ce7c88bf Trac #25105: ell_number_field.py takes a long time to test
>>> bb996e69ec Trac #25098: Fix LaTeX usage in Rings documentation
>>> eecf07e8c7 Trac #25095: polygon3d ignores the "alpha" (and equivalent 
>>> "opacity") argument
>>> 15b5aa2b60 Trac #25081: The polar of a polyhedron should carry the 
>>> backend used.
>>> 62a893aba3 Trac #25080: code for Cartesian factorization of posets
>>> 89ec1fb5c2 Trac 

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

[John H Palmieri]

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
**
File "src/sage/features/gap.py", line 41, in 
sage.features.gap.GapPackage._is_present
Failed example:
GapPackage("prim", spkg="database_gap").is_present()  # optional: 
database_gap
Expected:
FeatureTestResult('GAP package prim', True)
Got:
FeatureTestResult('GAP package prim', False)
**
1 item had failures:
   1 of   3 in sage.features.gap.GapPackage._is_present
[12 tests, 1 failure, 5.81 s]
--
sage -t --long src/sage/features/gap.py  # 1 doctest failed
--

Emmanuel, is this what you are seeing?

-- 
John



On Tuesday, May 15, 2018 at 5:46:00 AM UTC-7, Emmanuel Charpentier wrote:
>
> 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  # Timed out
> sage -t --long src/sage/groups/perm_gps/permgroup.py  # 1 doctest failed
> sage -t --long src/sage/features/gap.py  # 1 doctest failed
> --
>
> HTH,
>
> --
> Emmanuel Charpentier
>
>
> Le lundi 14 mai 2018 20:10:54 UTC+2, Volker Braun a écrit :
>>
>> 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
>>
>> 6fc1e20c66 (tag: 8.3.beta1) Updated SageMath version to 8.3.beta1
>> 8c327b9901 Trac #25258: Gurobi breaks lots of doctests in make ptestlong
>> 47a7327e12 Trac #25248: py3: fix sage.parallel.map_reduce
>> 7feb4d298c Trac #25244: LatticePoset: Add is_interval_dismantlable
>> 3e6075d57b Trac #25236: Deprecate various functions from old coercion 
>> model
>> c4b415fa9f Trac #25235: q-Stirling numbers of the second kind
>> 2c90815686 Trac #25224: Mismatch in the definition of dilog() between 
>> fricas and sympy
>> 3ab97b15d3 Trac #25223: Cleaning of the usage of BFS
>> bf0beabf6a Trac #25220: fix definite fricas integration
>> 88e1ed6d0e Trac #25216: py3: fix bytes handling bugs in sage.plot.animate
>> deae517486 Trac #25211: code should not depend ordering of codegrees
>> eb2f271af2 Trac #25203: Speed up FiniteField.zeta()
>> 22b8be8a05 Trac #25201: Use super() in MatrixSpace.__getitem__
>> 9a7f40d097 Trac #25200: Incorrect long element for signed permutations
>> eba77d3f14 Trac #25195: py3: fix segfault in element wrapper on Python 3
>> f5527d2184 Trac #25192: primitivity test for integral matrices
>> b3b4f75048 Trac #25186: Use ZZ.random_element for random_prime
>> 7e6c6ab9e5 Trac #25182: coherent output type for polynomial.degree()
>> 6aafae Trac #25174: conversion of I to fricas is wrong
>> 6a34919efb Trac #25169: py3: fixing print in sage-starts script
>> 80d4a17edc Trac #25161: Sphinx build hangs when a BaseException occurs
>> 6f130ae999 Trac #25146: Cleanup of AbstractPartitionDiagram
>> 41c9fffbe1 Trac #24966: package primecount 4.3
>> 72980a10a1 Trac #24890: Tensor product of lattices
>> 951fa49129 Trac #24460: py3: fixes to sage.libs.gap
>> e5af4884cc Trac #15508: Implement Fock space
>> 4756f04cbe Trac #25335: Missing imports in 
>> src/sage/geometry/polyhedron/base.py
>> faad356119 Trac #25133: Implement WQSym
>> b593af3371 Trac #25132: Define the class of SuperPartitions
>> c1a36a02ee Trac #25131: FQSym: add G basis
>> ad72cec5b8 Trac #25128: Have py_scalar_to_element convert gmpy2 numbers
>> 81f7d7a341 Trac #25121: fix edge color format in graphviz_string
>> 8821bb1454 Trac #25120: dot2tex edge coloring is broken
>> 80fa1be913 Trac #25117: some pyflakes cleanup for unused variables
>> fd8c5d4676 Trac #25112: perl_term_readline_gnu: Upgrade to 1.35 and patch 
>> away ncurses problem
>> bf6cbafbed Trac #25109: Upgrade cmake to 3.11.0
>> 07ce7c88bf Trac #25105: ell_number_field.py takes a long time to test
>> bb996e69ec Trac #25098: Fix LaTeX usage in Rings documentation
>> eecf07e8c7 Trac #25095: polygon3d ignores the "alpha" (and equivalent 
>> "opacity") argument
>> 15b5aa2b60 Trac #25081: The polar of a polyhedron should carry the 
>> backend used.
>> 62a893aba3 Trac #25080: code for Cartesian factorization of posets
>> 89ec1fb5c2 Trac #25075: pyflakes cleanup in combinat
>> 329c579bac Trac #25074: upgrade to ipywidgets 7.2.0
>> a5122d141e Trac #25067: Implement quantum group q-numbers
>> 054122ae77 Trac #25065: partition input is 

Re: [sage-release] Re: Release process

[Dima Pasechnik]

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 tickets/branches by fetching the integration branch, 
but I'd rather prefer this info
to be posted in case of these merge conflicts.


On Tuesday, May 15, 2018 at 4:07:25 PM UTC+1, Volker Braun wrote:
>
> 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 
> when I rewrite it.
>
>
>  
>
> On Tuesday, May 15, 2018 at 3:59:08 PM UTC+2, Erik Bray wrote:
>>
>> 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 in on the release process this is not 
>> >> a problem". 
>> > 
>> > 
>> > I agree that it's not a problem for the "sophisticated developer" who 
>> knows 
>> > what he is doing. But the more you advertise this secret branch, the 
>> larger 
>> > chance there is of abuse by non-sophisticated developers who have no 
>> clue. I 
>> > believe that this is the point that Maarten was trying to make. 
>>
>> I don't see much chance for "abuse".  Mostly all I'm talking about 
>> here is to do integration in a branch that's easy to identify and is 
>> documented (it can even be documented as "this branch is unstable so 
>> don't look at it unless you know what you're doing".  The worse 
>> someone can bite themselves is by maybe rebasing a branch on top of 
>> that branch, and then proposing that version of the branch for merging 
>> which might not always be for the best (though it might often be fine 
>> too).  To make this mistake would require knowing how to use rebase in 
>> the first place... 
>>
>> On Tue, May 15, 2018 at 3:49 PM, Jeroen Demeyer  
>> wrote: 
>> > 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. 
>>
>> Nope, but as I wrote upthread this discussion is still orthogonal to 
>> what I wanted to propose... 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Volker Braun]

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 
when I rewrite it.


 

On Tuesday, May 15, 2018 at 3:59:08 PM UTC+2, Erik Bray wrote:
>
> 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 in on the release process this is not 
> >> a problem". 
> > 
> > 
> > I agree that it's not a problem for the "sophisticated developer" who 
> knows 
> > what he is doing. But the more you advertise this secret branch, the 
> larger 
> > chance there is of abuse by non-sophisticated developers who have no 
> clue. I 
> > believe that this is the point that Maarten was trying to make. 
>
> I don't see much chance for "abuse".  Mostly all I'm talking about 
> here is to do integration in a branch that's easy to identify and is 
> documented (it can even be documented as "this branch is unstable so 
> don't look at it unless you know what you're doing".  The worse 
> someone can bite themselves is by maybe rebasing a branch on top of 
> that branch, and then proposing that version of the branch for merging 
> which might not always be for the best (though it might often be fine 
> too).  To make this mistake would require knowing how to use rebase in 
> the first place... 
>
> On Tue, May 15, 2018 at 3:49 PM, Jeroen Demeyer  > wrote: 
> > 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. 
>
> Nope, but as I wrote upthread this discussion is still orthogonal to 
> what I wanted to propose... 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

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

[Erik Bray]

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
regression somewhere.  I'm running ./sage -t -a --failed yet again,
but from my last run I got:

sage -t src/sage/libs/gap/all_documented_functions.py  # Timed out
sage -t src/sage/libs/gap/assigned_names.py  # Timed out
sage -t src/sage/manifolds/differentiable/affine_connection.py  # Timed out
sage -t src/sage/manifolds/differentiable/euclidean.py  # Timed out
sage -t src/sage/manifolds/differentiable/metric.py  # Timed out
sage -t src/sage/manifolds/differentiable/multivectorfield.py  # Timed out
sage -t src/sage/manifolds/differentiable/tensorfield.py  # Timed out
sage -t src/sage/plot/plot.py  # Timed out
sage -t src/sage/rings/padics/padic_base_leaves.py  # Timed out
sage -t src/sage/rings/padics/padic_lattice_element.py  # Timed out
(and interrupt failed)


Will try 16.04 (the current base for my Docker images) and 18.04 next.

On Tue, May 15, 2018 at 2:46 PM, Emmanuel Charpentier
 wrote:
> 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  # Timed out
> sage -t --long src/sage/groups/perm_gps/permgroup.py  # 1 doctest failed
> sage -t --long src/sage/features/gap.py  # 1 doctest failed
> --
>
> HTH,
>
> --
> Emmanuel Charpentier
>
>
> Le lundi 14 mai 2018 20:10:54 UTC+2, Volker Braun a écrit :
>>
>> 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
>>
>> 6fc1e20c66 (tag: 8.3.beta1) Updated SageMath version to 8.3.beta1
>> 8c327b9901 Trac #25258: Gurobi breaks lots of doctests in make ptestlong
>> 47a7327e12 Trac #25248: py3: fix sage.parallel.map_reduce
>> 7feb4d298c Trac #25244: LatticePoset: Add is_interval_dismantlable
>> 3e6075d57b Trac #25236: Deprecate various functions from old coercion
>> model
>> c4b415fa9f Trac #25235: q-Stirling numbers of the second kind
>> 2c90815686 Trac #25224: Mismatch in the definition of dilog() between
>> fricas and sympy
>> 3ab97b15d3 Trac #25223: Cleaning of the usage of BFS
>> bf0beabf6a Trac #25220: fix definite fricas integration
>> 88e1ed6d0e Trac #25216: py3: fix bytes handling bugs in sage.plot.animate
>> deae517486 Trac #25211: code should not depend ordering of codegrees
>> eb2f271af2 Trac #25203: Speed up FiniteField.zeta()
>> 22b8be8a05 Trac #25201: Use super() in MatrixSpace.__getitem__
>> 9a7f40d097 Trac #25200: Incorrect long element for signed permutations
>> eba77d3f14 Trac #25195: py3: fix segfault in element wrapper on Python 3
>> f5527d2184 Trac #25192: primitivity test for integral matrices
>> b3b4f75048 Trac #25186: Use ZZ.random_element for random_prime
>> 7e6c6ab9e5 Trac #25182: coherent output type for polynomial.degree()
>> 6aafae Trac #25174: conversion of I to fricas is wrong
>> 6a34919efb Trac #25169: py3: fixing print in sage-starts script
>> 80d4a17edc Trac #25161: Sphinx build hangs when a BaseException occurs
>> 6f130ae999 Trac #25146: Cleanup of AbstractPartitionDiagram
>> 41c9fffbe1 Trac #24966: package primecount 4.3
>> 72980a10a1 Trac #24890: Tensor product of lattices
>> 951fa49129 Trac #24460: py3: fixes to sage.libs.gap
>> e5af4884cc Trac #15508: Implement Fock space
>> 4756f04cbe Trac #25335: Missing imports in
>> src/sage/geometry/polyhedron/base.py
>> faad356119 Trac #25133: Implement WQSym
>> b593af3371 Trac #25132: Define the class of SuperPartitions
>> c1a36a02ee Trac #25131: FQSym: add G basis
>> ad72cec5b8 Trac #25128: Have py_scalar_to_element convert gmpy2 numbers
>> 81f7d7a341 Trac #25121: fix edge color format in graphviz_string
>> 8821bb1454 Trac #25120: dot2tex edge coloring is broken
>> 80fa1be913 Trac #25117: some pyflakes cleanup for unused variables
>> fd8c5d4676 Trac #25112: perl_term_readline_gnu: Upgrade to 1.35 and patch
>> away ncurses problem
>> bf6cbafbed Trac #25109: Upgrade cmake to 3.11.0
>> 07ce7c88bf Trac #25105: ell_number_field.py takes a long time to test
>> bb996e69ec Trac #25098: Fix LaTeX usage in Rings documentation
>> eecf07e8c7 Trac #25095: polygon3d ignores the "alpha" (and equivalent
>> "opacity") argument
>> 15b5aa2b60 Trac #25081: The polar of a polyhedron should carry the backend
>> used.
>> 62a893aba3 Trac #25080: code for Cartesian factorization of posets
>> 89ec1fb5c2 Trac #25075: pyflakes cleanup in combinat
>> 329c579bac Trac #25074: upgrade to ipywidgets 7.2.0
>> a5122d141e Trac #25067: Implement quantum group 

Re: [sage-release] Re: Release process

[Erik Bray]

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 in on the release process this is not
>> a problem".
>
>
> I agree that it's not a problem for the "sophisticated developer" who knows
> what he is doing. But the more you advertise this secret branch, the larger
> chance there is of abuse by non-sophisticated developers who have no clue. I
> believe that this is the point that Maarten was trying to make.

I don't see much chance for "abuse".  Mostly all I'm talking about
here is to do integration in a branch that's easy to identify and is
documented (it can even be documented as "this branch is unstable so
don't look at it unless you know what you're doing".  The worse
someone can bite themselves is by maybe rebasing a branch on top of
that branch, and then proposing that version of the branch for merging
which might not always be for the best (though it might often be fine
too).  To make this mistake would require knowing how to use rebase in
the first place...

On Tue, May 15, 2018 at 3:49 PM, Jeroen Demeyer  wrote:
> 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.

Nope, but as I wrote upthread this discussion is still orthogonal to
what I wanted to propose...

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Jeroen Demeyer]

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 you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Emmanuel Charpentier]

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 case, R) does not need extreme level of 
sophistication ; delegating these tasks to people able to follow some 
guidelines, read and interpret error messages and propose reasonably clean 
patches allow people who *are* sophisticated to use their time at more 
difficult tasks...

Therefore, I think that contributing to Sage should not *require* a 
sophisticated understanding of the finer points of git care and feeding...

--
Emmanuelk Charpentier

Le mardi 15 mai 2018 15:11:09 UTC+2, Jeroen Demeyer a écrit :
>
> 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 the "sophisticated developer" who 
> knows what he is doing. But the more you advertise this secret branch, 
> the larger chance there is of abuse by non-sophisticated developers who 
> have no clue. I believe that this is the point that Maarten was trying 
> to make. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Jeroen Demeyer]

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 the "sophisticated developer" who 
knows what he is doing. But the more you advertise this secret branch, 
the larger chance there is of abuse by non-sophisticated developers who 
have no clue. I believe that this is the point that Maarten was trying 
to make.


--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

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

[Emmanuel Charpentier]

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  # Timed out
sage -t --long src/sage/groups/perm_gps/permgroup.py  # 1 doctest failed
sage -t --long src/sage/features/gap.py  # 1 doctest failed
--

HTH,

--
Emmanuel Charpentier


Le lundi 14 mai 2018 20:10:54 UTC+2, Volker Braun a écrit :
>
> 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
>
> 6fc1e20c66 (tag: 8.3.beta1) Updated SageMath version to 8.3.beta1
> 8c327b9901 Trac #25258: Gurobi breaks lots of doctests in make ptestlong
> 47a7327e12 Trac #25248: py3: fix sage.parallel.map_reduce
> 7feb4d298c Trac #25244: LatticePoset: Add is_interval_dismantlable
> 3e6075d57b Trac #25236: Deprecate various functions from old coercion model
> c4b415fa9f Trac #25235: q-Stirling numbers of the second kind
> 2c90815686 Trac #25224: Mismatch in the definition of dilog() between 
> fricas and sympy
> 3ab97b15d3 Trac #25223: Cleaning of the usage of BFS
> bf0beabf6a Trac #25220: fix definite fricas integration
> 88e1ed6d0e Trac #25216: py3: fix bytes handling bugs in sage.plot.animate
> deae517486 Trac #25211: code should not depend ordering of codegrees
> eb2f271af2 Trac #25203: Speed up FiniteField.zeta()
> 22b8be8a05 Trac #25201: Use super() in MatrixSpace.__getitem__
> 9a7f40d097 Trac #25200: Incorrect long element for signed permutations
> eba77d3f14 Trac #25195: py3: fix segfault in element wrapper on Python 3
> f5527d2184 Trac #25192: primitivity test for integral matrices
> b3b4f75048 Trac #25186: Use ZZ.random_element for random_prime
> 7e6c6ab9e5 Trac #25182: coherent output type for polynomial.degree()
> 6aafae Trac #25174: conversion of I to fricas is wrong
> 6a34919efb Trac #25169: py3: fixing print in sage-starts script
> 80d4a17edc Trac #25161: Sphinx build hangs when a BaseException occurs
> 6f130ae999 Trac #25146: Cleanup of AbstractPartitionDiagram
> 41c9fffbe1 Trac #24966: package primecount 4.3
> 72980a10a1 Trac #24890: Tensor product of lattices
> 951fa49129 Trac #24460: py3: fixes to sage.libs.gap
> e5af4884cc Trac #15508: Implement Fock space
> 4756f04cbe Trac #25335: Missing imports in 
> src/sage/geometry/polyhedron/base.py
> faad356119 Trac #25133: Implement WQSym
> b593af3371 Trac #25132: Define the class of SuperPartitions
> c1a36a02ee Trac #25131: FQSym: add G basis
> ad72cec5b8 Trac #25128: Have py_scalar_to_element convert gmpy2 numbers
> 81f7d7a341 Trac #25121: fix edge color format in graphviz_string
> 8821bb1454 Trac #25120: dot2tex edge coloring is broken
> 80fa1be913 Trac #25117: some pyflakes cleanup for unused variables
> fd8c5d4676 Trac #25112: perl_term_readline_gnu: Upgrade to 1.35 and patch 
> away ncurses problem
> bf6cbafbed Trac #25109: Upgrade cmake to 3.11.0
> 07ce7c88bf Trac #25105: ell_number_field.py takes a long time to test
> bb996e69ec Trac #25098: Fix LaTeX usage in Rings documentation
> eecf07e8c7 Trac #25095: polygon3d ignores the "alpha" (and equivalent 
> "opacity") argument
> 15b5aa2b60 Trac #25081: The polar of a polyhedron should carry the backend 
> used.
> 62a893aba3 Trac #25080: code for Cartesian factorization of posets
> 89ec1fb5c2 Trac #25075: pyflakes cleanup in combinat
> 329c579bac Trac #25074: upgrade to ipywidgets 7.2.0
> a5122d141e Trac #25067: Implement quantum group q-numbers
> 054122ae77 Trac #25065: partition input is ignored when casting DiGraph as 
> BipartiteGraph
> 09f6b467c5 Trac #25064: more conversions from http to https
> 7f5a1dad2b Trac #25063: py3: get rid of __cmp__ in interfaces
> 430abb3957 Trac #25062: another typo ticket, yet
> ae77a27f60 Trac #25061: Replace MatrixFactory.__call__ by an ordinary 
> function
> 920bfc0f16 Trac #25060: py3: more rich comparison for multivariate 
> polynomials
> eec16d96bd Trac #25059: py3: get rid of some  __cmp__ in string monoids
> d7b39179bc Trac #25058: corrections to input for posets
> 7993a2d1d3 Trac #25053: py3: remove __cmp__ in free monoids
> 6513b621f8 Trac #25052: Add DESTDIR support for openblas
> ab02054314 Trac #25042: Add DESTDIR support for freetype
> bc875efff0 Trac #15597: Quasi-shuffle product
> 670713abd7 Trac #25129: Fix "offline" viewing of threejs plots on Cygwin
> 6cfeb59db4 Trac #25038: Use sage-dist-helpers for curl and gc
> 235703c6da Trac #25037: Add destdir support and other cleanup for ntl
> fbcf50432c Trac #25036: Code cleanup in plot3d
> a698014552 Trac #25023: Adds function to compute quadratic defect
> 1f7f75b42f Trac #25022: change_ring broken on polynomials
> f997efffd1 Trac #25018: Bug in shuffle product `ShuffleProduct_w1w2`
> 1c38098666 Trac #25016: Add PyCygwin 

Re: [sage-release] Re: Release process

[Erik Bray]

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 release manager who
>> decides what happens.
>
> Even without switching to the model Erik is advocating, it could perhaps
> be useful to have additional integration branches where the *reviewer*
> would be supposed to merge a branch when setting the corresponding
> ticket to positive review. The release manager would remain free to use
> these branches or not when preparing the actual release.

I mean, one thing that drives me up the wall is being told with some
regularity that a ticket of mine has a "merge conflict" without any
indication of what it actually *conflicts* with, even though the
ticket merges fine with the "develop" branch.  This is because Volker
has a "private" integration branch that he's merging things into.
(I've in the past glibly called this "secret", and while no it's not
*actually* secret it's not exactly easy to find--I don't understand
why it isn't just a standard branch like "master", or at least
something with an identifiable name that is fetched by default).
While Volker could at least tell us what the conflicting files are we
are otherwise left to guess since we don't even know what's been
merged into that branch.  I think it would be better if this branch
were easily found and were documented--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.

All that said, I see no reason not to make release-specific branches.
On most projects I would make such a branch simultaneously with
tagging a beta release of a new X.Y version.  Sage's development
process uses "beta" a little differently that I would normally, and
that's fine--that's just a bikeshed.  But with Sage's version
nomenclature it would at least make sense to create a release-specific
branch concurrently with the first *release candidate*.  With such a
branch available, development can still continue apace while critical
bugfixes can be backported the release branch.  This is a completely
normal thing to do and is plenty advantageous.  I don't see the harm
in asking people who are interested in Sage development to get used to
the idea that there can be multiple lines of development
simultaneously (in this case just two...)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.