On Thu, Jun 11, 2015 at 1:24 PM, David Perkinson wrote:
> Yes, I think it will be much more efficient to address these changes all at
> once. I would really prefer that, if possible.
>
I downloaded the code as a tarball and "manually" installed it (as
opposed to using git).
I didn't find any pr
> What if they would be willing to systematically
> review my revisions according to the usual conventions (e.g.,
> http://doc.sagemath.org/html/en/developer/reviewer_checklist.html#chapter-review)?
> Does this seem like a reasonable way to proceed?
Yes, there is nothing wrong with that. Anybody c
I have two bright former students who would probably be willing to help.
One is in currently in the CS program at UW and the other will start the
PhD program in math at Berkeley next fall. Both know sandpile theory well
(the former is a co-author), and both have experience using the Sage,
esp
The following two should succeed:
make ptestlong
make doc-pdf
On Friday, June 12, 2015 at 8:36:39 PM UTC+2, David Perkinson wrote:
>
> One constructive thing I can do, at least, is revise the code to the point
> that patchbot is happy. Up to this point, I have only known of the test
> "sage
One constructive thing I can do, at least, is revise the code to the point
that patchbot is happy. Up to this point, I have only known of the test
"sage -t". All tests passed for my revised code. The problems patchbot
is flagging all seem to be issues with building documentation: indentatio
>
>
> The guideline is not a rule, but it has not been put there for no
> reason either. I have had to do *very* long reviews of a diff that
> wasn't half as long as yours. I certainly would not start another one
> when, from the look of your diff file, the changes are so unrelated
> that you
> Yes, I think it will be much more efficient to address these changes all at
> once. I would really prefer that, if possible.
>
> I had seen the "reasons-to-invalidate-tickets" statement but was hoping this
> was a guideline, subject to context, and not a law.
What you have to accept is that by
Yes, I think it will be much more efficient to address these changes all at
once. I would really prefer that, if possible.
I had seen the "reasons-to-invalidate-tickets" statement but was hoping
this was a guideline, subject to context, and not a law.
Thanks.
On Thursday, June 11, 2015 at 8:3
On Thu, Jun 11, 2015 at 11:31 AM, kcrisman wrote:
>
>>
>> http://doc.sagemath.org/html/en/developer/trac.html#reasons-to-invalidate-tickets
>
>
> I think what Nathann is trying to say is that it might be good to split this
> up into smaller pieces. However, given the trouble you had getting git t
>
> http://doc.sagemath.org/html/en/developer/trac.html#reasons-to-invalidate-tickets
>
I think what Nathann is trying to say is that it might be good to split
this up into smaller pieces. However, given the trouble you had getting
git to work, that might be something somewhat technically inf
http://doc.sagemath.org/html/en/developer/trac.html#reasons-to-invalidate-tickets
Nathann
--
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...@g
11 matches
Mail list logo
