#18229: Upgrade R to 3.2.0
-------------------------------------+-------------------------------------
Reporter: charpent | Owner: charpent
Type: enhancement | Status: needs_review
Priority: minor | Milestone: sage-6.7
Component: packages: | Resolution:
standard | Merged in:
Keywords: r-project | Reviewers: Vincent Delecroix
Authors: Emmanuel | Work issues:
Charpentier, Leif Leonhardy | Commit:
Report Upstream: Reported | bc2269e64ccb2f5fcc83cf62085eeeb53d7e1dcf
upstream. No feedback yet. | Stopgaps:
Branch: |
u/leif/R_upgrade_with_new_patch |
Dependencies: #18254 |
-------------------------------------+-------------------------------------
Comment (by leif):
Replying to [comment:78 charpent]:
> Replying to [comment:77 leif]:
> > ? Fixing the bug in `R_PCRE` certainly belongs to upgrading R to
3.2.0, since the new version introduced the bug, and as you have seen, it
hits at least some of us (depending on the system configuration).
>
> 1. This version introduced the bug : you're right, as far as I can tell.
Your case seems to be a corner case.
Did you read the upstream report?
[[BR]]
> 2. It's the same problem : no.
Same as what?
[[BR]]
> This is, as far as I understand, a problem with the build infrastructure
of Sage.
Nope. The same happens outside of Sage.
[[BR]]
> The new R version just revealed a latent bug in a very loosely related
part of this infrastructure.
Bug in Sage's infrastructure? I don't get the point.
[[BR]]
> If I'd found this bug, I'd have opened a distinct ticket (T2) and made
the present ticket (T1) depend on the new ticket (T2).
Well, technically that doesn't really make sense, since I cannot fix
something that hasn't yet been included. (#18254 is ''slightly''
different as it modifies an existing file, namely `spkg-install`.) My
changes are based on your branch.
I would agree if we could make this ticket depend on upstream, but then it
wouldn't be possible to (positively) review it before upstream decided on
a solution.
[[BR]]
> That way, each different problem would have been identified in the
tickets database. As should have been done when a previous version of R
opened a Cygwin-related saga...
We at least have different commits with IMHO meaningful commit messages...
(which unfortunately often isn't the case).
You probably know my opinion on (not) bumping patch levels and discarding
the package changelog we used to have for years.
Sometimes it is better to also fix "unrelated" minor issues (such as the
typo) on a ticket dealing with a package (nowadays probably less than it
was with "legacy" spkgs), since otherwise they'll simply never get fixed,
either because nobody opens individual tickets for them, or the tickets
just rotten.
The prerequisite for inclusion of a new (or upgraded) package is that it
builds/works on all supported platforms, so fixing build issues (and
probably fixing doctests, cf. the PARI upgrade at #18340, which was
motivated by an initially seemingly unrelated problem with GNU make)
belongs to the ticket that introduces (or upgrades) a package.
There are other issues where it perfectly makes sense to open (a
metaticket and) separate (sub-)tickets, e.g. to let Sage build with GCC
5.x (four tickets for four different packages which need fixing), or to
let Sage build with `clang` (dozens of tickets).
''[page overflow]''
--
Ticket URL: <http://trac.sagemath.org/ticket/18229#comment:86>
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.
