Remove Yutani from authors

[yutannihilation]

@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

[andy-thomason]

@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 happy to back you if you need change in the CRAN requirements.

[CGMossa]

Dear @yutannihilation, I'd like to preface this, with expressing how much I personally have enjoyed, and respect your contributions to extendr overall. And also, let me be clear that every message, every opinion, and everything you've contributed, I've personally thought about the utmost respect.

I would urge you to rethink this PR; There are reasons, but it is mostly important to be clear, that this is about ensuring that you understand, that we will do whatever it takes to be in agreement for what rextendr is, and what values it will strive for.

With that out of the way, I would also like to make clear, that the discourse around this has been hastily, inconsiderate, and frankly childish. I didn't know you wanted to completely ignore CRAN going forward. You have rust powered r-packages on CRAN. @eitsupi is on the discord, and writes about their publishing journey on CRAN. And there are numerous discussions about fulfilling CRAN requirements everywhere within this organisation.

I've no idea where this sudden disdain for CRAN came from, and why rextendr cannot contain good starting point for publishing on CRAN. Frankly, none of you made issues, or wrote in an objective way about what it is you want.

I'm not sure if it was our fault (@Ilia-Kosenkov included) in whatever brought this on; There are PRs that come in, they seem to be in accordance with what else happens, and we act accordingly. When @eitsupi made numerous contributions, we quickly ensured that they be added as a contributor. Or atleast I'm 100% sure that this has been discussed and done.

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. If there is something to be discussed, please do it in a clear, and comprenhensive way. In-fighting is fine, but this declaration from you, and the one from @eitsupi about forking rextendr is an overreaction, and very convoluted.

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.

[andy-thomason]

+1 to adding @eitsupi to the Authors and acknowledging the hard work of all the members of the team.

[yutannihilation]

@andy-thomason

have you managed to express your views to the CRAN community?

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 Sorry if you feel offended, but this is not something like protest or attack. It's solely my fault if this looks sudden to you. I've expressed my concerns about making things complex by considering CRAN requirements several times, but I didn't argue strongly because I didn't want to discourage the development of the package.

Refrain from merging this until I've come back to the discussion please.

Sure, but I have nothing to discuss here. Really. Please don't get me wrong.

[Ilia-Kosenkov]

I will add only one thing: you pretty much built these libraries, {rextendr} and extendr. Even if you want to distance yourself from it and never ever contribute, you should still remain an author because, well, you are one of the original authors.

[yutannihilation]

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.

[andy-thomason]

@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?

[yutannihilation]

What would be your demands to nail to the door of the church of CRAN?

I don't demand anything.

Is it impossible for Rust packages to be accepted?

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/.

[andy-thomason]

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

In case not, it is desirable to include the library sources in the package and compile them as part of package installation

• Rust code from crates is statically linked. Cargo will not download a crate with the same version twice in a session.

If the sources are too large, it is acceptable to download them as part of installation

• so including Cargo.lock would be fine, surely.

We are not downloading pre-compiled software, unless you include cargo and rustc. They certainly don't include gcc and clang as pre-compiled software.

Maybe if we wrote a set of rules for CRAN Rust packages ourselves, we could get them to agree to them?

[yutannihilation]

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.

[CGMossa]

No worries. Merging.

[yutannihilation]

Thanks for understanding.

[malcolmbarrett]

@yutannihilation thanks for all your work in this area