#16711: Upgrade R to version 3.1.1
-------------------------------------+-------------------------------------
Reporter: charpent | Owner:
Type: enhancement | Status: positive_review
Priority: minor | Milestone: sage-6.3
Component: packages: | Resolution:
standard | Merged in:
Keywords: r-project | Reviewers: Nathann Cohen
Authors: Emmanuel | Work issues:
Charpentier, Nathan Cohen | Commit:
Report Upstream: N/A | 752190c8b5dcd7964ddbae59a4f7899100d787be
Branch: | Stopgaps:
u/charpent/upgrade_r_to_version_3_1_1|
Dependencies: |
-------------------------------------+-------------------------------------
Changes (by charpent):
* status: needs_review => positive_review
Comment:
Replying to [comment:5 ncohen]:
> Helloooooooooo !!
>
> > I can't : this has deep interferences with the Sage build system,
which I do not undetstand yet.
>
> Nonono it does not. Those spkg-src script are not used automatically in
any way, they are just there to help us update packages. I also used it to
do a "proper reviewing job", because I can't just accept a binary files of
20mb+ trusting that you just copied the original files. Technically you
could have modified anything in there without me noticing, and the code
will run on everybody's machine.
After re-reading the docs, I agree with you. I forgot this one (thus
demonstrating the interest of cross-review...:-).
> So I checked that I could produce the spkg myself and that the hash were
the same. I did so with the lines I added to the file.
>
> > Furthermore, this fixes a problem '''different''' of the original one.
This kind of ticket hijacking is likely to delay the solution of both
hijacker and hijacked issues.
>
> `O_o`
>
> Hey, the commit only adds 3 lines to a file to make what you just did
easier, and your ticket has been created 21 hours ago. There is no
hijacking going on, and 21 hours is not what can be called a "long delay"
either.
Hmmm... My previous drop-in of R 3.0 was delayed for months by an attempt
to make it compile on Cygwin without a previously known bug...
> > Would you cate to take a look at #16629 and give us ypur advice ? BTW,
this ticket still awaits review...
>
> I don't understand much about the management of spkg in Sage. And I had
to query a dictionary for the definition of "munch".
>
> > I can't either : I am the author, and the whole point of a systematic
peer review is to avoid too-hasty incorporation of
incomplete/foolhardy/misguided patches. Saved my ass a couple of times
already...
>
> It is my commit. I wrote the code and your review it. And I review your
code. If you can review a 3-lines commit on another ticket it can probably
be done here too. Sage's rules are not sacred, they are here to avoid
mistake. The point of reviewing each other's code definitely makes sense,
so if every code is reviewed by somebody who is not the author there is no
problem.
>
> I can swear that I saw it happen quite a lot of times already. Some
patches even have the same two names in the "reviewer" and the "authors"
field. Everybody checks the other's code, that's all.
I didn't know that.
> > On the other hand, '''you''' can give it positive review if you think
that the branch fixes the specific problem the ticket was aimed at ;-)
Ditto for #16629, BTW...
>
> I did my review, and my review included a commit. If you don't agree
with it for religious reasons another reviewer will come.
No religious feelings here. You convinced me.
> Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/16711#comment:7>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
