-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Yutani from authors #315
Remove Yutani from authors #315
Conversation
@yutannihilation have you managed to express your views to the CRAN community? As the author of some influential packages, you should carry some weight and we would be |
Dear @yutannihilation, I'd like to preface this, with expressing how much I personally have enjoyed, and respect your I would urge you to rethink this PR; There are reasons, but it is mostly important to be clear, With that out of the way, I would also like to make clear, that the discourse around this has been hastily, I've no idea where this sudden disdain for CRAN came from, and why I'm not sure if it was our fault (@Ilia-Kosenkov included) in whatever brought this on; There are PRs that come in, I think overall, we are all sick and tired of the lack of progress, but resorting to contrived in-fighting isn't to my liking. I have some real life BS to deal with now, but this is indeed a priority for me, and I assure you that I'll get back to this. Refrain from merging this until I've come back to the discussion please. |
+1 to adding @eitsupi to the Authors and acknowledging the hard work of all the members of the team. |
I did. A lot. I sent many emails publicly on the R-package-devel mailing list and privately in response to the death sentence from the CRAN maintainers. @CGMossa
Sure, but I have nothing to discuss here. Really. Please don't get me wrong. |
I will add only one thing: you pretty much built these libraries, |
I get your point, but this is my decision. I want to withdraw my name from the package. Let me make it clear. I have different opinions on various topics around extendr, but I believe we can discuss and somehow find an agreement or compromise in general. But, this is different. CRAN is treated like a religion and none of my words reaches anyone. I'm in despair. Let me rest in peace. |
@yutannihilation What would be your demands to nail to the door of the church of CRAN? Is it impossible for Rust packages to be accepted? |
I don't demand anything.
It's possible. I'm just saying it's not suitable by its nature. If you want more longer version of explanation, please read https://yutani.rbind.io/post/rust-and-cran-repository-policy/. |
Just looking at the paragraph: "Where a package wishes to make use of a library not written solely for the package, the package installation should first look to see if it is already installed and if so is of a suitable version. In case not, it is desirable to include the library sources in the package and compile them as part of package installation. If the sources are too large, it is acceptable to download them as part of installation, but do ensure that the download is of a fixed version rather than the latest. Only as a last resort and with the agreement of the CRAN team should a package download pre-compiled software." On the
We are not downloading pre-compiled software, unless you include cargo and rustc. Maybe if we wrote a set of rules for CRAN Rust packages ourselves, we could get them |
Ah, okay, that blog post was a bit too old. Sorry. But, your points are what we have already passed long ago, yet my conclusion stays the same. Sorry, could you stop this? It's so painful for me to explain these complex details just to let you know it's meaningless. Again, please let me rest in peace. |
No worries. Merging. |
Thanks for understanding. |
@yutannihilation thanks for all your work in this area |
@CGMossa @Ilia-Kosenkov
This doesn't mean I won't contribute to rextendr anymore. But, as it's becoming clear the rextendr package aims for creating a CRAN-ready R-Rust package, I'd like to make it clear that I cannot support the direction. You might have thought that I'm interested in doing things right for CRAN, but it's not. I'd like to make CRAN right.
edit: Here, "make CRAN right," is probably not what you expect, so let me add a few words. Ultimately, CRAN is not a suitable place for Rust-powered packages. It's not because the CRAN maintainers are irrational, but because of its nature (my take). I don't attempt to change the nature. I don't think CRAN can be the final goal of most of the developers of Rust-powered packages by any means. That said, to my eyes, the policy had and has several inconsistencies and strange obsessions. I'd like to fix them as far as I can because these will be a pain to those who has some unavoidable reason to place their Rust-powered packages on CRAN (and simply because I dislike inconsistency).
I really don't think it's a good idea to blindly admire CRAN without discussing the pros and cons, considering CRAN's requirements are so weird (while reasonable to some extent from a viewpoint). But, I don't mean at all to change the project's direction as it seems this is what everyone wants (except for me). The purpose of this pull request is solely clarification. Please go ahead. It's just I'm tired of the endless struggle.
As a side note, rextendr should consider including @eitsupi as an author. He is the fourth contributor at the time of writing this, and made many contributions related to CRAN. So, if CRAN is important to the project, there's no reason to prevent him from involving.
https://github.com/extendr/rextendr/graphs/contributors