Re: [Rd] R CMD check warning about compiler warning flags

[Juan Telleria]

However, and hope not to be off-topic, a git repository (github, gitlab,
codeplex, etc., not just solely github) could constitute a tidy approach,
and make things easier to R Core :)

By putting the focus on version control, the line of changes made with each
commit (With the possibility to reverse changes), and not verbose e-mails.

Juan

I strongly disagree. Are you aware that github is a commercial
>> company, github inc. [1] ?
>> What about gitlab? or Microsoft's codeplex? There are other services
>> similar to github, why github?
>> What happens if github goes out of business?
>>
>> R-project should be maintained in the academic network and under
>> auspices of universities.
>>
>>
>>  [*]  GitHub, Inc.
>>https://en.wikipedia.org/wiki/GitHub
>>
>
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check warning about compiler warning flags

[Juan Telleria]

M... I see... thank you Suzen.

Juan


> I strongly disagree. Are you aware that github is a commercial
> company, github inc. [1] ?
> What about gitlab? or Microsoft's codeplex? There are other services
> similar to github, why github?
> What happens if github goes out of business?
>
> R-project should be maintained in the academic network and under
> auspices of universities.
>
>
>  [*]  GitHub, Inc.
>https://en.wikipedia.org/wiki/GitHub
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Collaborative Wiki: Mediawiki

[Juan Telleria]

Dear R Developers,

I create this e-mail, linked to "Collaborative Wiki for fostering Open
Innovation in R", for going straight into the point:

After studing multiple wikies (Confluence, xwiki, Mediawiki) for a
collaborative approach to R Documentation, I finally came up that Mediawiki
was the best for managing documentation for being:

   - 100% Open Source.
   - Simple, tidy, neat interface.
   - Documentation Focused (no forums, no other things).
   - Being the one Wikipedia usses is really an assurance that it will
   never go away, and each second spent on it is worthy.
   - Anyone can collaborate, update files up to 40 MB, but there is a
   strict version control on the wiki :), just as wikipedia has.

So I requested on Miraheze (https://meta.miraheze.org/wiki/Miraheze)
Community Driven Wiki Farms that they set up a wiki as a *Sandbox for
testing* (Not for real use in production):

https://kbrproject.miraheze.org/wiki/Main_Page

You can test it an play with it whatever you want; and assess if it could
constitute a good option for managing contributed R documentation.

Juan

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check warning about compiler warning flags

[Suzen, Mehmet]

On 26 December 2017 at 00:00, Juan Telleria  wrote:
> Maybe I'm new, and forgive my ignorance, but maybe in the future (~ X years
> from now) the R Project could be managed entirely from github, by doing

I strongly disagree. Are you aware that github is a commercial
company, github inc. [1] ?
What about gitlab? or Microsoft's codeplex? There are other services
similar to github, why github?
What happens if github goes out of business?

R-project should be maintained in the academic network and under
auspices of universities.


 [*]  GitHub, Inc.
   https://en.wikipedia.org/wiki/GitHub

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check warning about compiler warning flags

[Juan Telleria]

Maybe I'm new, and forgive my ignorance, but maybe in the future (~ X years
from now) the R Project could be managed entirely from github, by doing
pull requests and only R Core having commit rights...

Would make the forking process also easier... And could be a good roadmap.

But we're not using git, we're just sending emails back and forth.  I don't
> need to run svn to get some useful information from the number 73909.
> Winston's web page at https://github.com/wch/r-source/commit/2e80059 does
> display the number 73909 if you know where to look, but his email doesn't
> contain it.
>
> I don't know about other svn users, but I'd be perfectly content to read
> something like "This appears to have been added in rev 73909 (diff shown
> here: https://github.com/wch/r-source/commit/2e80059)."
>
> Duncan Murdoch

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check warning about compiler warning flags

[Duncan Murdoch]

On 25/12/2017 7:00 AM, Iñaki Úcar wrote:

2017-12-25 12:30 GMT+01:00 Duncan Murdoch :

The one negative aspect of Winston's effort is caused by this weakness. If
you tell me that something happened in revision 73909, I know it was recent.
If you tell me that something appeared in commit 2e80059, it wastes my time
looking up that commit and putting it in context.


The output from "git describe" is something similar to an svn
revision: it describes the number of commits since the previous
annotated tag. Something like -<#commits>-g,
e.g., v3.5.0-56-1234567.


But we're not using git, we're just sending emails back and forth.  I 
don't need to run svn to get some useful information from the number 
73909.  Winston's web page at 
https://github.com/wch/r-source/commit/2e80059 does display the number 
73909 if you know where to look, but his email doesn't contain it.


I don't know about other svn users, but I'd be perfectly content to read 
something like "This appears to have been added in rev 73909 (diff shown 
here: https://github.com/wch/r-source/commit/2e80059)."


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check warning about compiler warning flags

[Iñaki Úcar]

2017-12-25 12:30 GMT+01:00 Duncan Murdoch :
> The one negative aspect of Winston's effort is caused by this weakness. If
> you tell me that something happened in revision 73909, I know it was recent.
> If you tell me that something appeared in commit 2e80059, it wastes my time
> looking up that commit and putting it in context.

The output from "git describe" is something similar to an svn
revision: it describes the number of commits since the previous
annotated tag. Something like -<#commits>-g,
e.g., v3.5.0-56-1234567.

Iñaki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check warning about compiler warning flags

[Duncan Murdoch]

On 22/12/2017 10:46 AM, Marc Schwartz wrote:

Hi,

See inline below.



On Dec 22, 2017, at 9:12 AM, Martin Maechler  wrote:


Duncan Murdoch 
on Thu, 21 Dec 2017 14:23:13 -0500 writes:



On 21/12/2017 1:02 PM, Winston Chang wrote:

On recent builds of R-devel, R CMD check gives a
WARNING when some compiler warning flags are detected,
such as -Werror, because they are non-portable. This
appears to have been added in this commit:
https://github.com/wch/r-source/commit/2e80059


That is not the canonical R sources.


Yes, that is obvious. The main page for that repository
says it is a mirror of the R sources, right at the top. I
know that because I put the message there, and because I
see it every time I visit the repository. If you have a
good way of pointing people to the changes made in a
commit with the canonical R sources, please let us
know. I and many others would be happy to use it.



The usual way is just to refer to the revision number,
i.e. "This appears to have been added in rev 73909".



People who don't have the sources checked out can see the
diff on your Github mirror using



https://github.com/wch/r-source/search?q="trunk@73909"=Commits



and following the listed search hit. (Thanks to Thierry
Onkelinx for helping me with this.) This only works for
commits to the trunk.  I guessed that something like



https://github.com/wch/r-source/search?q="R-3-4-branch@73937"=Commits



would work if the commit was to the 3.4 branch, but
apparently not.  I don't know how to find those commits.
Presumably there's a way, but I don't know it.



Another possibility is that someone could set up (or
already has?) one of the web viewers (WebSVN, etc.) for
the real repository.  That would be better for those of us
who are SVN users, but probably harder for Git users.



Duncan Murdoch


As you know I had setup (the first few versions of) the svn at
  https://svn.r-project.org/

at the time, I wanted to keep that machine protected as much as
possible and had decided not to install any other apache
modules and svn - niceties just such that the server would run
minimal services and hence would be minimally vulnerable.

The times have changed though and I will look into adding WebSVN
to svn.r-project.org  as one of the  first things in 2018.

Martin Maechler



Martin,

Just to play a bit of a devil's advocate here, WebSVN has not been 
updated/maintained since June of 2011, so is a number of years old at this 
point. That should raise some reasonable concerns over bugs, security issues 
and related matters.

To put that in perspective, the last update to WebSVN was around the time that 
R 2.13.1 was released.

That general pattern, of SVN clients not being actively maintained, seems to be 
consistent across a number of the web based (and even browser plugin based) SVN 
clients, which may in turn, be an indication of the general shift to Git in 
recent years, much as the shift from CVS to SVN occurred years ago.

In researching other SVN clients, the few that still seem to be actively 
maintained are typically dedicated desktop clients/GUIs, that in some cases are 
closed source and/or are OS specific.

One of the few web based SVN clients that still seems to be actively maintained 
is Trac (https://trac.edgewall.org), however it is under a modified BSD 
license, which may raise some issues and from what I can tell, may be more 
complicated in terms of set up, since it also supports bug tracking, wiki and 
other functionality. As with any such application, there would be ongoing 
maintenance issues as well.


There's also ViewVC which still seems to be active.


I am not advocating any particular solution. I just want to point out potential issues 
with WebSVN and raise for discussion, what options may make sense to consider, based upon 
how many folks might actually use such "live" web based functionality versus 
remote SVN access via a desktop client, which is certainly an option, since they won't 
have write access anyway.


As a general principle in open source projects the work should be done 
by the people who want to use the product.  Winston wanted git access to 
the R sources, and he put it together: bravo!


It's unfortunate that git doesn't really support svn completely, because 
it is superior in many ways.  However, it isn't uniformly better than 
svn. Its very weak support for sequential labels means that switching to 
it would be a lot of work for R Core, and that group doesn't have a lot 
of spare time to waste.


The one negative aspect of Winston's effort is caused by this weakness. 
If you tell me that something happened in revision 73909, I know it was 
recent.  If you tell me that something appeared in commit 2e80059, it 
wastes my time looking up that commit and putting it in context.


Duncan Murdoch



Also, a number of the Git desktop clients also support Git SVN 
(https://git-scm.com/docs/git-svn), for compatibility, which