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

Proposal: Move idna_adapter crate to servo/rust-url repository #1009

Open
Foorack opened this issue Dec 18, 2024 · 7 comments
Open

Proposal: Move idna_adapter crate to servo/rust-url repository #1009

Foorack opened this issue Dec 18, 2024 · 7 comments

Comments

@Foorack
Copy link

Foorack commented Dec 18, 2024

Currently, the idna_adapter crate is hosted under the "github.com/hsivonen" prefix.

Given that idna_adapter's sole publicly reported dependant is the idna crate, I propose moving idna_adapter source code to the servo/rust-url repository.

image

  • Centralization: Simplifies management and maintenance by centralizing related codebases.
  • Consistency: Ensures consistent development and versioning of interdependent crates.
  • Security: Enhances security by consolidating code under the main servo organization, reducing the risk of fragmentation.
  • Transparency: Improves transparency and trust by having all related code in the main servo repository.
@Manishearth
Copy link
Member

This was a deliberate and hopefully temporary choice while we were still figuring out exactly how to do this. I believe @hsivonen is open to moving this into the servo org or this repo based on what the servo TSC decides.

This repo seems fine by me.

@Manishearth
Copy link
Member

@hsivonen what was the blocker to doing this before? Just needing to wait for a TSC meeting?

@Sytten
Copy link

Sytten commented Dec 18, 2024

Came here to say the same thing, it feels very wrong for a crate that is now included in a lot of codebases via the url crate to be hosted on the personal account of a maintainer.

@hsivonen
Copy link
Collaborator

I wanted to move the repo from under github.com/hsivonen/ to under github.com/servo/ , but the Servo Technical Steering Committee was uneasy with taking more repos at this time. The idea of moving rust-url itself out of the servo GitHub org was floated by a TSC member. Settling that issue one way or another is probably in practice a prerequisite for moving the idna_adapter and idna_mapping repos.

Due to the way the testing and development mechanics of the idna_adapter crate go, it would be inconvenient to put the crate in the rust-url repo. I think idna_adapter should remain in a separate repo so that it's easy to switch branches in a checkout independently of the branch of the rust-url repo that has been checked out.

@Manishearth
Copy link
Member

Due to the way the testing and development mechanics of the idna_adapter crate go, it would be inconvenient to put the crate in the rust-url repo. I think idna_adapter should remain in a separate repo so that it's easy to switch branches in a checkout independently of the branch of the rust-url repo that has been checked out.

I don't think it would be hard to write such a test in-tree. I'm happy to take on that work if that is the only blocker.

@hsivonen
Copy link
Collaborator

hsivonen commented Dec 20, 2024

How do you mean? idna_adapter currently has 4 branches that are relevant to switch between while having the rust-url checkout in a single state: main, unicode-rs, no-unicode, and icu4x-trunk.

@Manishearth
Copy link
Member

@hsivonen we're not actually testing them that way in either repo.

What we are testing is 1.2.0 and 1.0.0. I don't see a problem with having two folders in tree here, idna-adapter and idna-adapter-1.x. The 1.x folder is excluded from the workspace but uses path dependencies for tests.

We could also maintain an idna-adapter-1.x branch on rust-url and merge rust-url code back into it on occasion. I think I'd prefer this.

I think there are a couple techniques available for this.

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

No branches or pull requests

4 participants