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

[Foorack]

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.

• 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]

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]

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

[Sytten]

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]

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]

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]

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]

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

[nicoburns]

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

While there was a little pushback from the Servo TSC on the issue of more repos, I think it was mostly a case of "we feel like this ought to be decided and managed by rust-url maintainers" (which according to MAINTAINERS.md is just @valenting (is there anyone else who ought to be on that list?)) and the TSC not wanting to subvert the "rust-url maintainers" authority for a request from someone (@hsivonen) who was unknown to them.

I think there was also a suggestion that idna-adapter could just live in this repo (the main rust-url repo) along with the main idna crate. But the issue was really more of an "authority vacuum" than any substantial concerns.