[rkward-devel] RKWard Git repos up for testing

[Thomas Friedrichsmeier]

Hi,

dropping the CCs. I don't think Jeremy and Nicolás will care about this part 
of the discussion.

On Tuesday 11 November 2014 15:15:56 meik michalke wrote:
> i didn't want to push yet, just wanted to clone the repo and couldn't
> because my key was missing. but that will be solvend soon.

Ok. Should be solved, now. Hint for everybody else: If you don't have a KDE 
developer account, clone from 
  git://anongit.kde.org/scratch/tfry/rkward-svn-import.git

> > Well that's mostly a separate discussion, though. I have now added a new
> > "organization" on github: rkward-community. Tell me your account names,
> > there, and I'll add you, then move over the external plugins repo.
> 
> they call me unDocUMeantIt

Ok. The external plugins repo is live at
  https://github.com/rkward-community/external-plugins
and ready for use. I added an intial readme, feel free to modify.

> hm, i think CRAN is the wrong place for these packages. sooner or later, it
> will definitely result in pointless discussions about new rules in the repo
> policies and we would have to rebuild and resubmit everything each time. for
> instance, a while ago it was decided that on CRAN it is forbidden(!) to
> ship your source code tarball with a copy of the GPL, because they "have it
> on the homepage"; and they forced me to take one package off CRAN again
> because it uses an unexported function that the R development core team
> recommends(!) to use. so even if our packages would be considered ok today,
> that might no longer be the case tomorrow.
> 
> at the same time there's little to gain -- our packages are only useful with
> RKWard anyway, so it's not so much an obstacle to have them in a repo that
> is almost only known to the application. i'd really prefer to do that
> ourselves. all we need is a little webspace.

Well, the one thing going for CRAN is that we're including it as a repo, 
anyway. But yes, we should definitely have at least a fallback in place, and 
if we need a fallback, then there's little gain in using CRAN, in addition. 
Except, just a thought, CRAN _could_ be an interesting option while 
transitioning (whenever that becomes current).

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20141112/5c38bacf/attachment.sig>