Re: [sage-devel] NTL 1v0.1.0

[Victor Shoup]

Good! But it should be determined if there is an interface that ntl could 
provide so that this problem goes away 

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

Re: [sage-devel] NTL 1v0.1.0

['Bill Hart' via sage-devel]

Hans does seem to fix most bugs that are reported unless they require 
extensive rewriting or aren't considered bugs. It looks like this code was 
written with the expectation that it would be maintained, so I'd just 
report it to him [1].

Bill.

[1] https://www.singular.uni-kl.de/index.php/singular-report-bugs.html

On Tuesday, 18 October 2016 06:18:58 UTC+2, Victor Shoup wrote:
>
> I see.  I don't do it on purpose... 
> I looked at some singular source files, but I don't know if I have the 
> most recent. But it looks like they are trying to look inside ntl's ZZ 
> representation.  That's a big no no. Right now, the only semi efficient way 
> to do this with the existing interface is to use ZZToBytes (or something 
> like that).  I could add some special routines for direct gmp bignum 
> conversions, if there was a demand for that. 

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

Re: [sage-devel] NTL 1v0.1.0

[Victor Shoup]

That said, I think the quickest fix is to replace static_cast with 
(long*). But it's not a good long term solution. 

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

Re: [sage-devel] NTL 1v0.1.0

[Francois Bissey]

> On 18/10/2016, at 17:18, Victor Shoup  wrote:
> 
> I see.  I don't do it on purpose... 
> I looked at some singular source files, but I don't know if I have the most 
> recent. But it looks like they are trying to look inside ntl's ZZ 
> representation.  That's a big no no. Right now, the only semi efficient way 
> to do this with the existing interface is to use ZZToBytes (or something like 
> that).  I could add some special routines for direct gmp bignum conversions, 
> if there was a demand for that. 

The code is not recent as far as I can tell. The stated purpose here:

/// NAME: convertZZ2CF
///
/// DESCRIPTION:
/// Routine for conversion of integers represented in NTL as Type ZZ to
/// integers in Factory represented as canonicalform.
/// To guarantee the correct execution of the algorithm the characteristic
/// has to equal zero.
///
/// INPUT:  The value coefficient of type ZZ that has to be converted
/// OUTPUT: The converted Factory-integer of type canonicalform

And in some case they use the quoted snippet.
This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

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

Re: [sage-devel] NTL 1v0.1.0

[Victor Shoup]

I see.  I don't do it on purpose... 
I looked at some singular source files, but I don't know if I have the most 
recent. But it looks like they are trying to look inside ntl's ZZ 
representation.  That's a big no no. Right now, the only semi efficient way to 
do this with the existing interface is to use ZZToBytes (or something like 
that).  I could add some special routines for direct gmp bignum conversions, if 
there was a demand for that. 

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

Re: [sage-devel] NTL 1v0.1.0

[Francois Bissey]

> On 18/10/2016, at 16:49, Victor Shoup  wrote:
> 
> Interesting. Looks like the singular code is using internal, undocumented NTL 
> interfaces. I work very hard to keep the documented interfaces stable and 
> reliable, but I can't guarantee anything for undocumented interfaces.  If 
> singular is going to do that, they will have to use ifdefs or something to 
> work around the issue. Or ask me to provide an interface for some 
> functionality that they need and that I can maintain. My guess is that this  
> is related to changes I made in the transition to v10.
> 

And you should make life difficult for abuser of undocumented
or internal interfaces. There is a special place for such people…

They already do ifdef, this is a larger extract than the
error message:
const long * rep =
#if NTL_MAJOR_VERSION <= 6
  static_cast( a.rep );
#else
  static_cast( a.rep.rep ); // what about NTL7?
#endif

François

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

Re: [sage-devel] NTL 1v0.1.0

[Victor Shoup]

Interesting. Looks like the singular code is using internal, undocumented NTL 
interfaces. I work very hard to keep the documented interfaces stable and 
reliable, but I can't guarantee anything for undocumented interfaces.  If 
singular is going to do that, they will have to use ifdefs or something to work 
around the issue. Or ask me to provide an interface for some functionality that 
they need and that I can maintain. My guess is that this  is related to changes 
I made in the transition to v10.

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

Re: [sage-devel] NTL 1v0.1.0

[François Bissey]

On 15/10/16 03:28, Victor Shoup wrote:

After much foot dragging, and with the help and encouragement of folks
here at sage-devel,
I've finally got around to making (nearly) all of the packaging/build
features that were requested.
The big ones are locally generated libtool and $(MAKE).
I did not implement that Singular/NTL_NEW_OP patch --- that is a
Singular problem
that should be fixed in Singular.



Hum, not sure it is fixed, but something that look new happened :)
NTLconvert.cc: In function ‘CanonicalForm convertZZ2CF(const NTL::ZZ&)’:
NTLconvert.cc:509:38: error: invalid static_cast from type ‘const 
raw_ptr {aka _ntl_gbigint_body* const}’ to type ‘long int*’

   static_cast( a.rep.rep ); // what about NTL7?
  ^
Makefile:1205: recipe for target 'NTLconvert.lo' failed

This is building singular 4.0.3p3. Haven't tried a build including
the old to see if that makes the problem go away.

Francois

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

[sage-devel] Re: slow doctest number_field_element.pyx on my machine

[Jakob Kroeker]

this is now https://trac.sagemath.org/ticket/21719#ticket

Am Dienstag, 4. Oktober 2016 22:13:50 UTC+2 schrieb Volker Braun:
>
> I've seen that time out often on the buildbot, too. Please, somebody 
> replace the test in there by something more reasonable.
>
>
>
> On Tuesday, October 4, 2016 at 9:53:13 PM UTC+2, Jakob Kroeker wrote:
>>
>> on my machine (fedora 23, 32 Bit) the test
>>
>> sage -t --long --warn-long 127.3 src/sage/rings/number_field/
>> number_field_element.pyx
>>
>>
>>
>> takes 1397.8 seconds (10 times more)
>>
>> And thus the patchbot test run for sage 7.4.beta6 fails 
>>
>> I have aIntel(R) Core(TM)2 Duo CPU E8200  @ 2.66GHz ; it should 
>> not be THAT slow.
>>
>> Any suggestions?
>>
>>
>>
>>
>>
>>
>>
>>
>>

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

Re: [sage-devel] Overcommitted memory and error handling

[Jeroen Demeyer]

On 2016-10-17 17:40, Jori Mäntysalo wrote:

but due to overcommit there is no exception raised.


That's really the fault of the OS, not the fault of Sage.

Side comment: don't use

x = malloc(n)
memset(x, 0, n)

There is calloc for that.

And *certainly* don't use NULL, use 0 for that.

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

[sage-devel] Overcommitted memory and error handling

[Jori Mäntysalo]

Is it even theoretically possible to handle something like Graph(10^10)? 
That will crash at the line


memset(self.vertices,  NULL, nverts * self.hash_length * 
sizeof(SparseGraphBTNode *))

Before that we have

sig_malloc(nverts * self.hash_length * . . .
if not . . .
raise RuntimeError("Failure allocating memory.")

but due to overcommit there is no exception raised. Setting (as root) the 
value of /proc/sys/vm/overcommit_memory will not help, but may change 
error message given.


--
Jori Mäntysalo

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 5:00 PM, Ralf Stephan  wrote:
> On Monday, October 17, 2016 at 11:42:46 AM UTC+2, Erik Bray wrote:
>>
>> On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey
>>  wrote:
>> > Release early, release often. In my experience in the last 8 years,
>> > especially release often - it has slowed down a bit, but it is still
>> > often by any means.
>>
>> I'm afraid that's just not very useful--it's a platitude.
>
>
> Disagree. The higher the release frequency the better streamlined is the
> release process because the maintainer has more occasions to think
> about it. The less pain is a quick bugfix release, although that
> specifically
> may not be a problem with Sage.

I don't disagree, but see what I just wrote above--it's a mantra not a process.

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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 4:48 PM, Jeroen Demeyer  wrote:
> On 2016-10-17 16:32, Erik Bray wrote:
>>
>> If a critical
>> bug is found in released software it makes absolute sense to
>> prioritize a release for that bug.
>
>
> First of all, there have occasionally been bugfix releases of Sage:
> * http://www.sagemath.org/changelogs/sage-5.0.1.txt
> * http://www.sagemath.org/changelogs/sage-5.4.1.txt
> * http://www.sagemath.org/changelogs/sage-6.1.1.txt
> * http://www.sagemath.org/changelogs/sage-6.4.1.txt
>
> Such critical bugs are very rare in Sage. I cannot recall any bug in a
> released version of Sage in the last year or so that would justify a bugfix
> release. Remember that Sage is tested well before releases, on the patchbot,
> on the buildbot and by developers running beta/rc versions.

Bug fix releases are good even for non-critical bugs.  Just because
"Sage is tested well before releases" doesn't mean there are not bugs.
It's great to be able to get fixes to users quickly without having to
go through a longer release testing process that is necessary for
bigger releases with more features, new dependencies, etc.  This will
be especially important as we move toward trying to better decouple
sagelib from its dependencies in how it's developed.

I'm also not sure how you're defining "critical bugs".  I think all
bugs are fairly important to fix within the framework of a manageable
maintenance cycle.  Having such a cycle means you get those fixes out
to users faster--as Francois wrote "release early, and release often".
Again, I apologize for dismissing it as a "platitude".  It's a good
mantra, especially for bug fixes.  It's just not a *plan*.

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

Re: [sage-devel] Milestones

[Ralf Stephan]

On Monday, October 17, 2016 at 11:42:46 AM UTC+2, Erik Bray wrote:
>
> On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey 
>  wrote: 
> > Release early, release often. In my experience in the last 8 years, 
> > especially release often - it has slowed down a bit, but it is still 
> > often by any means. 
>
> I'm afraid that's just not very useful--it's a platitude.


Disagree. The higher the release frequency the better streamlined is the
release process because the maintainer has more occasions to think
about it. The less pain is a quick bugfix release, although that 
specifically
may not be a problem with Sage.

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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 4:50 PM, Jeroen Demeyer  wrote:
> On 2016-10-17 16:32, Erik Bray wrote:
>>
>> If a critical
>> bug is found in released software it makes absolute sense to
>> prioritize a release for that bug.
>
>
> Besides, isn't this exactly what I said? That the "release schedule should
> depend on the urgency of open issues." If there is a very important bug in a
> released version, schedule a bugfix release.

Yes, we're in agreement with that.  But that doesn't dictate an entire
release schedule for *all* releases.

That's great that Sage has done patch releases before.  What's the
process for doing that in general?

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

Re: [sage-devel] Milestones

[Jeroen Demeyer]

On 2016-10-17 16:32, Erik Bray wrote:

If a critical
bug is found in released software it makes absolute sense to
prioritize a release for that bug.


Besides, isn't this exactly what I said? That the "release schedule 
should depend on the urgency of open issues." If there is a very 
important bug in a released version, schedule a bugfix release.


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

Re: [sage-devel] Milestones

[Jeroen Demeyer]

On 2016-10-17 16:32, Erik Bray wrote:

If a critical
bug is found in released software it makes absolute sense to
prioritize a release for that bug.


First of all, there have occasionally been bugfix releases of Sage:
* http://www.sagemath.org/changelogs/sage-5.0.1.txt
* http://www.sagemath.org/changelogs/sage-5.4.1.txt
* http://www.sagemath.org/changelogs/sage-6.1.1.txt
* http://www.sagemath.org/changelogs/sage-6.4.1.txt

Such critical bugs are very rare in Sage. I cannot recall any bug in a 
released version of Sage in the last year or so that would justify a 
bugfix release. Remember that Sage is tested well before releases, on 
the patchbot, on the buildbot and by developers running beta/rc versions.


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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 3:44 PM, Jeroen Demeyer  wrote:
> On 2016-10-17 15:27, Erik Bray wrote:
>>
>> What problems does it solve?  First of all, I already mentioned
>> one--nobody but the "release manager" knows when a release is expected
>> to come out
>
>
> Who cares when a release is expected to come out?

I would think anyone who uses or works on Sage.  If they don't, they
should.  A transparent release cycle is sort of at the heart of
software product development--everything else stems from that,
including more immediately important things.

>> what the purpose of that release is, and what one can
>> expect to be in it.  That's a problem in of itself.
>
>
> You are talking about a user-centric Changelog here? That's indeed something
> that is missing, although I consider that a different issue from a roadmap
> (a Changelog is made after the fact, a roadmap before).
>
>> How do you
>> communicate to users how often/when they can expect releases?
>
>
> Do users care?
>
>> How,
>> also, do you communicate that to developers?  How is one supposed to
>> know the urgency of an issue if one doesn't know the release schedule?
>
>
> I my opinion, the urgency of an issue should never depend on the release
> schedule. It should be the other way around: the release schedule should
> depend on the urgency of open issues.

No, sorry, but that's completely backwards.  Or at least it would be
if Sage had a sane process for issuing patch releases.  If a critical
bug is found in released software it makes absolute sense to
prioritize a release for that bug.  You can't do that if all
development is in one linear branch and making a release to fix a bug
does not force other, non-critical, non-fix changes on users.  It's
also harder for developers because it makes a blocker issue becomes a
blocker to continuing much any development, as well as releases.

A lot of the problems with working on Sage, as we know, is the tight
coupling between Sage itself and its build environment and dependency
set.  It is universally acknowledged that this is a problem and should
be worked on.  It is difficult to do this without establishing some
better procedures.

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

Re: [sage-devel] Milestones

[Jori Mäntysalo]

On Mon, 17 Oct 2016, Jeroen Demeyer wrote:


Who cares when a release is expected to come out?


I do, but very, very slightly.

We have a maintenance break at every monday after second tuesday of the 
week. (That is, six days after Microsoft patch day.) I could plan upgrades 
if I know in advance when the new version will be available.


--
Jori Mäntysalo

Re: [sage-devel] Milestones

[Jeroen Demeyer]

On 2016-10-17 15:27, Erik Bray wrote:

What problems does it solve?  First of all, I already mentioned
one--nobody but the "release manager" knows when a release is expected
to come out


Who cares when a release is expected to come out?


what the purpose of that release is, and what one can
expect to be in it.  That's a problem in of itself.


You are talking about a user-centric Changelog here? That's indeed 
something that is missing, although I consider that a different issue 
from a roadmap (a Changelog is made after the fact, a roadmap before).



How do you
communicate to users how often/when they can expect releases?


Do users care?


How,
also, do you communicate that to developers?  How is one supposed to
know the urgency of an issue if one doesn't know the release schedule?


I my opinion, the urgency of an issue should never depend on the release 
schedule. It should be the other way around: the release schedule should 
depend on the urgency of open issues.


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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 2:15 PM, Jeroen Demeyer  wrote:
> On 2016-10-17 11:33, Erik Bray wrote:
>>
>> I'm mostly just talking about a policy that generates a (rough)
>> release schedule.
>
>
> Which problems would that solve? I don't really see the problem with the
> current "release whenever it's done" way of doing things, where "whenever
> it's done" is largely arbitrary.

I mostly brought this up in the first place just because I was
confused about how milestones are being used (they aren't).  It would
be nice if they were used more as intended though.

What problems does it solve?  First of all, I already mentioned
one--nobody but the "release manager" knows when a release is expected
to come out, or what the purpose of that release is, and what one can
expect to be in it.  That's a problem in of itself.  How do you
communicate to users how often/when they can expect releases?  How,
also, do you communicate that to developers?  How is one supposed to
know the urgency of an issue if one doesn't know the release schedule?

That's just the actual schedule though.  Really that's not my chief
concern (though it would be good to have).  More broadly, a lack of
development formality here leads to various other unnecessary
complications and difficulties.  I could go on and on here, but you
wouldn't be hearing anything new from me...

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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 2:08 PM, Jeroen Demeyer  wrote:
> On 2016-10-17 11:38, Erik Bray wrote:
>>
>> But you're using a "milestone" to set what is effectively a resolution
>> status.  Why should "normal" users be able to set
>> sage-duplicate/invalid/wontfix?  That seems like a decision for a
>> maintainer to make, at which point they can close the ticket.

That would seem fine to me, if

> The way I see it: it's a way for a normal user to indicate a *proposal* to
> close a ticket as invalid or whatever. Then the actual closing is done by
> the release manager.

...that actually happened with any consistency :)

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

Re: [sage-devel] Milestones

[Jeroen Demeyer]

On 2016-10-17 11:33, Erik Bray wrote:

I'm mostly just talking about a policy that generates a (rough)
release schedule.


Which problems would that solve? I don't really see the problem with the 
current "release whenever it's done" way of doing things, where 
"whenever it's done" is largely arbitrary.


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

Re: [sage-devel] Milestones

[Jeroen Demeyer]

On 2016-10-17 11:38, Erik Bray wrote:

But you're using a "milestone" to set what is effectively a resolution
status.  Why should "normal" users be able to set
sage-duplicate/invalid/wontfix?  That seems like a decision for a
maintainer to make, at which point they can close the ticket.


The way I see it: it's a way for a normal user to indicate a *proposal* 
to close a ticket as invalid or whatever. Then the actual closing is 
done by the release manager.


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

[sage-devel] Re: puzzling dev.upload_ssh_key() in developer manual

[B Krishnan Iyer]

Thanks, I will definitely look into it.  

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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 12:29 PM, Jori Mäntysalo  wrote:
> On Mon, 17 Oct 2016, Francois Bissey wrote:
>
>> To move to the kind of release schedule you are talking about
>> we’ll need a new release manager who has the vision for this kind
>> of things.
>
>
> What is Volker's vision? I.e. do he have some plan in his head about when to
> release 7.6?

I suspect probably.  I don't believe it's ad-hoc.  But I don't know
that this is documented.  I find it strange, personally, that this is
left entirely up to the release manager and not by some larger
consensus.

> I think that having two branches is just too much. In perfect world we could
> have LTS with bugfixes only and so on, but we have not enought manpower for
> that. But we could have some kind of decision like "7.6rc0 will be out at
> the end of April 2017."

I think it's rather bad to not be doing this.

What some large projects do, like Python, is to have multiple release
managers where each person is in charge of a specific release.  So you
can have a release manager specifically dedicated to upcoming patch
releases who take care of backporting fixes and the like.  This isn't
often too much work--most fixes are easy to backport--only a few
aren't.

The release managers work together, but meanwhile you have someone
entirely else in charge of getting the next feature release out.

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

Re: [sage-devel] Milestones

[Jori Mäntysalo]

On Mon, 17 Oct 2016, Francois Bissey wrote:


To move to the kind of release schedule you are talking about
we’ll need a new release manager who has the vision for this kind
of things.


What is Volker's vision? I.e. do he have some plan in his head about when 
to release 7.6?


I think that having two branches is just too much. In perfect world we 
could have LTS with bugfixes only and so on, but we have not enought 
manpower for that. But we could have some kind of decision like "7.6rc0 
will be out at the end of April 2017."


--
Jori Mäntysalo

Re: [sage-devel] Re: Customizin failed login -page

[Jori Mäntysalo]

On Mon, 17 Oct 2016, Dima Pasechnik wrote:


  See https://sage.sis.uta.fi/ . I just learnt that our students
  do not see
  the text "This is part of services available to students of SIS
  unit. To
  get an account see (link)this page(/link)."


I certainly see this


Sorry, I was unclear. They "see" it in techical sense, but mostly don't 
read or notice.


("Hear but not listen", I don't know if there is same kind of verb pair 
for visual reception.)


--
Jori Mäntysalo

[sage-devel] Re: Customizin failed login -page

[Dima Pasechnik]

On Monday, October 17, 2016 at 6:46:52 AM UTC, Jori Mäntysalo wrote:
>
> See https://sage.sis.uta.fi/ . I just learnt that our students do not see 
> the text "This is part of services available to students of SIS unit. To 
> get an account see (link)this page(/link)." 
>

I certainly see this; perhaps it depends upon the browser (e.g. we gave up 
on supporting IE long ago)
 

>
> A wish for those making frontend(s) to SageMath: please make it easy to 
> customize failed login -page. 
>
> -- 
> Jori Mäntysalo 
>

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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 11:54 AM, Francois Bissey
 wrote:
>
>> On 17/10/2016, at 22:42, Erik Bray  wrote:
>>
>> On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey
>>  wrote:
>>>
 On 17/10/2016, at 22:33, Erik Bray  wrote:

 My point is, as it is I see no way to divine when or why a Sage
 release is coming out.
>>>
>>> Release early, release often. In my experience in the last 8 years,
>>> especially release often - it has slowed down a bit, but it is still
>>> often by any means.
>>
>> I'm afraid that's just not very useful--it's a platitude.  It's
>> especially made worse by the lack of maintenance branches and patch
>> releases.  I agree patch releases should be frequent.  For a project
>> like sage feature releases should be fairly frequent too, but with
>> care not break compatibility.
>
> Platitude or not, that’s the reality I have been experiencing.
> Maintenance branch (or LTS release) have been brought up before,
> usually by people coding for a living, but it never got anywhere.
> I am fairly certain that it is a factor in said people getting less
> active over time.

Right--sorry--I didn't mean to sound dismissive.  It's not a bad
policy either but it helps, both developers and users, to have some
guidance.

> To move to the kind of release schedule you are talking about
> we’ll need a new release manager who has the vision for this kind
> of things.

Not necessarily--Volker does a good job.  This isn't just something
for a single person to dictate, but rather something that needs to be
worked on as a community to decide what's best.  As long as the
release manager is active in that discussion, they don't necessarily
need to have the "vision".  It does help to have someone write a
prototype (either based on existing community discussion or just by
fiat, to be discussed after).  But that can be anyone involved at a
high level in the project.

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

Re: [sage-devel] Milestones

[Francois Bissey]

> On 17/10/2016, at 22:42, Erik Bray  wrote:
> 
> On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey
>  wrote:
>> 
>>> On 17/10/2016, at 22:33, Erik Bray  wrote:
>>> 
>>> My point is, as it is I see no way to divine when or why a Sage
>>> release is coming out.
>> 
>> Release early, release often. In my experience in the last 8 years,
>> especially release often - it has slowed down a bit, but it is still
>> often by any means.
> 
> I'm afraid that's just not very useful--it's a platitude.  It's
> especially made worse by the lack of maintenance branches and patch
> releases.  I agree patch releases should be frequent.  For a project
> like sage feature releases should be fairly frequent too, but with
> care not break compatibility.

Platitude or not, that’s the reality I have been experiencing.
Maintenance branch (or LTS release) have been brought up before,
usually by people coding for a living, but it never got anywhere.
I am fairly certain that it is a factor in said people getting less
active over time.

To move to the kind of release schedule you are talking about
we’ll need a new release manager who has the vision for this kind 
of things. 

François

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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 11:40 AM, Jori Mäntysalo  wrote:
> On Mon, 17 Oct 2016, Erik Bray wrote:
>
>> I'm mostly just talking about a policy that generates a (rough)
>> release schedule.
>
>
> OK, so you mean something like Fedora release, where it was decided about
> half a year ago that version 25 will be out at 2016-11-08 (and that was
> later changed to 2016-11-15).
>
> In principle doable. It would mean that Volker won't change beta to rc until
> some predefined date, and will make the change unless there is a very good
> reason to release still one beta.

Something like that, yes.  It doesn't even have to be that
precise--experience shows that beta testing/release candidates can
hold things up if they expose major issues.  One way to deal with that
is to estimate, based on experience, how long release testing
typically takes (one can even go back through history and get some
quantitative evidence for this).  Another is to not set exact release
dates, but do set dates for cutting off the main branch to a release
branch, where from that point forward only fixes will be merged (it's
good to make a branch so that normal development can continue in the
main branch in the meantime).

Regardless, for the dates, it is still very useful to set rough
estimates based on a policy like you described.  This helps
contributors plan how to target work they wish to contribute to a
particular release.  Sage is fortunate that it is not commercial
software and doesn't have paying customers (like RedHat does) who
expect things at specific times.  But we can still do better to
communicate a plan--this can help making the software itself more
stable too.

Here's an example of a release plan I helped develop for Astropy:
https://github.com/astropy/astropy-APEs/blob/master/APE2.rst  It isn't
set in stone--it's been amended once or twice since its inception as
we gained experience with how well previous versions of the plan were
working.  But for the most part it's been quite stable.

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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey
 wrote:
>
>> On 17/10/2016, at 22:33, Erik Bray  wrote:
>>
>> My point is, as it is I see no way to divine when or why a Sage
>> release is coming out.
>
> Release early, release often. In my experience in the last 8 years,
> especially release often - it has slowed down a bit, but it is still
> often by any means.

I'm afraid that's just not very useful--it's a platitude.  It's
especially made worse by the lack of maintenance branches and patch
releases.  I agree patch releases should be frequent.  For a project
like sage feature releases should be fairly frequent too, but with
care not break compatibility.

> The release criteria seems to be give a bit of polish after a number
> of interesting commits are in.

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

Re: [sage-devel] Milestones

[Jori Mäntysalo]

On Mon, 17 Oct 2016, Erik Bray wrote:


I'm mostly just talking about a policy that generates a (rough)
release schedule.


OK, so you mean something like Fedora release, where it was decided about 
half a year ago that version 25 will be out at 2016-11-08 (and that was 
later changed to 2016-11-15).


In principle doable. It would mean that Volker won't change beta to rc 
until some predefined date, and will make the change unless there is a 
very good reason to release still one beta.


--
Jori Mäntysalo

Re: [sage-devel] Milestones

[Francois Bissey]

> On 17/10/2016, at 22:33, Erik Bray  wrote:
> 
> My point is, as it is I see no way to divine when or why a Sage
> release is coming out.

Release early, release often. In my experience in the last 8 years,
especially release often - it has slowed down a bit, but it is still
often by any means.
The release criteria seems to be give a bit of polish after a number
of interesting commits are in.

François

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

Re: [sage-devel] Milestones

[Erik Bray]

On Fri, Oct 14, 2016 at 5:01 PM, Jeroen Demeyer  wrote:
> On 2016-10-14 16:23, Erik Bray wrote:
>>
>> sage-duplicate/invalid/wontfix is a terrible "milestone" and I
>> wouldn't mind getting rid of that too.  That's a resolution status for
>> an issue, not project goal.
>
>
> Normal non-admin users cannot set a resolution, but they can set a
> milestone.

But you're using a "milestone" to set what is effectively a resolution
status.  Why should "normal" users be able to set
sage-duplicate/invalid/wontfix?  That seems like a decision for a
maintainer to make, at which point they can close the ticket.

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

Re: [sage-devel] Milestones

[Erik Bray]

On Mon, Oct 17, 2016 at 11:23 AM, Jori Mäntysalo  wrote:
> On Mon, 17 Oct 2016, Erik Bray wrote:
>
>> Does Sage have *any* kind of roadmap planning?
>
>
> No.
>
> What kind of roadmap it could be? If some developers are interested in graph
> theory, how to make them to add more linear algebra code to Sage?

It doesn't necessarily need to be in terms of features (e.g. "this
release will contain graph theory updates only").  That's not how you
plan a release roadmap, especially not one that goes well out into the
future.  There are lots of ways to do this and there is no one right
way.

I'm mostly just talking about a policy that generates a (rough)
release schedule.  Then if you have "some developers interested in
graph theory" if they have specific features they wish to work on you
can assign that work to an existing planned release.  If they don't
think they'll be able to finish the work, assuming it's not absolutely
critical it doesn't need to hold up the release and can be moved to
the next applicable release.

My point is, as it is I see no way to divine when or why a Sage
release is coming out.

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

Re: [sage-devel] Milestones

[Jori Mäntysalo]

On Mon, 17 Oct 2016, Erik Bray wrote:


Does Sage have *any* kind of roadmap planning?


No.

What kind of roadmap it could be? If some developers are interested in 
graph theory, how to make them to add more linear algebra code to Sage?


--
Jori Mäntysalo

Re: [sage-devel] Milestones

[Erik Bray]

On Fri, Oct 14, 2016 at 5:25 PM, Volker Braun  wrote:
> I don't really use the milestones except for the
> sage-duplicate/invalid/wontfix which indicates that there is nothing to
> merge.
>
> We don't really use trac for roadmap planning so there is no real
> significance to milestones, I guess.

Does Sage have *any* kind of roadmap planning?

> On Friday, October 14, 2016 at 4:07:06 PM UTC+2, Jeroen Demeyer wrote:
>>
>> As far as I know, the only real use-case for milestone is a milestone
>> like `sage-duplicate/invalid/wontfix` or `sage-pending`. I think that
>> every milestone of the form `sage-X.Y` is essentially treated
>> equivalently.
>>
>> So, we might as well git rid of the `sage-X.Y` milestones completely.
>> But the release manager can correct me if I'm wrong.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [sage-devel] Milestones

[Erik Bray]

On Fri, Oct 14, 2016 at 7:24 PM, Jori Mäntysalo  wrote:
> On Fri, 14 Oct 2016, Jeroen Demeyer wrote:
>
>> As far as I know, the only real use-case for milestone is a milestone like
>> `sage-duplicate/invalid/wontfix` or `sage-pending`. I think that every
>> milestone of the form `sage-X.Y` is essentially treated equivalently.
>
>
> I normally use "sage-N" and mark myself as the author when I plan to do
> something in near future, and "sage-(N+1)" rarely when I guess that version
> N will be out before I got something done. I have used "sage-wishlist" few
> times when I have an idea. If I report a bug, I use "sage-N" and left
> author-field empty if I am not sure that I'll make patch myself.
>
>  * * *
>
> But we don't have any plans like "Version 8 will be out about q1/2018 and
> will have mostly more support for numerical linear algebra.", and so
> milestones are not really used.

Yeah, I guess not.  That's too bad...

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

[sage-devel] Customizin failed login -page

[Jori Mäntysalo]

See https://sage.sis.uta.fi/ . I just learnt that our students do not see 
the text "This is part of services available to students of SIS unit. To 
get an account see (link)this page(/link)."


A wish for those making frontend(s) to SageMath: please make it easy to 
customize failed login -page.


--
Jori Mäntysalo