Skip to content
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

Merged
merged 1 commit into from
Sep 6, 2023

Conversation

yutannihilation
Copy link
Contributor

@yutannihilation yutannihilation commented Sep 1, 2023

@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
Copy link

@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
Copy link
Member

CGMossa commented Sep 1, 2023

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
Copy link

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

@yutannihilation
Copy link
Contributor Author

@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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link

@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
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor Author

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
Copy link
Member

CGMossa commented Sep 6, 2023

No worries. Merging.

@CGMossa CGMossa merged commit bdb1b0f into extendr:main Sep 6, 2023
17 checks passed
@yutannihilation
Copy link
Contributor Author

Thanks for understanding.

@yutannihilation yutannihilation deleted the remove-yutani-from-authors branch September 6, 2023 23:25
@malcolmbarrett
Copy link
Collaborator

@yutannihilation thanks for all your work in this area

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants