Consider converting to a standalone repo

[tarcieri]

This repo is configured as a fork of https:/chyh1990/yaml-rust but that repo is abandoned and it seems like this repo is becoming the de facto fork.

In that case, you might consider "detaching" your fork:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/detaching-a-fork

Notably forks have bad UX for contributors, since they steer contributions towards the upstream repo they were forked from, which can lead to people accidentally opening PRs against that repo instead of yours.

[davvid]

I was having the same thought.

[davvid]

But, this was what kept me back from doing this in other repos:

The new repository will not retain any of its issues, pull requests, wikis, stars, watchers, comments, child forks, or other metadata that may currently be associated with your current fork.

[davvid]

Hmm.. so I had recently deleted my fork of yaml-rust because github wouldn't let me create a fork off of this repository because I already had one forked off of chyh1990.

So, I deleted it and recreated it. When I recreated my fork, I forked off of this repository.

I tested pushing a branch over and the github UI does correctly target the pull requests to this fork, not the root repository.

The "forked from chyh1990" link is really the only usability wrinkle, since that steers users to the other repository.

which can lead to people accidentally opening PRs against that repo instead of yours

This seems like a relatively minor issue. The alternative to deleting this repo would be to create a yaml-rust2 org and a brand new repository can be created in that namespace, but I'm not sure if that's something @Ethiraric wants to do, so I'll leave that decision up to them.

I guess I can start watching the original repo and if there's issues/PRs we can always respond asking them to look over here. It's too bad github doesn't expose a, "make this repo a root," option.

I hope I'm not downplaying your concerns.

[tarcieri]

@davvid re: "The new repository will not retain any of its issues, pull requests, wikis, stars, watchers, comments, child forks, or other metadata that may currently be associated with your current fork."

That all means it's better to do it sooner or later. This repo currently has two open issues, no open PRs, ~50 stars, and is otherwise not that popular. Detaching from the fork is indeed a somewhat painful operation, and it's only going to get harder and harder as the repo gets more popular when there is actually a backlog of PRs.

[Ethiraric]

which can lead to people accidentally opening PRs against that repo instead of yours

That is a huge problem to me. I don't really think having an org for that is this worthwhile, as this project is fairly small.

This however makes me wonder if we should change the identity of this project. It was named yaml-rust2, because I wanted to have it just as a replacement of yaml-rust, so that people who used yaml-rust could easily change their Cargo and get a maintained version of the parser. The decisions we have made (and will have to make) may steer us away from the idea of a "stable" crate with close to no change in its API. We've already had 3 backward incompatible change and maybe, while detaching the fork and creating a standalone project, we could take advantage of it to rename the project and abandon this "stable" weight that may hinder our ability to have yaml-rust2 evolve?

[tarcieri]

I will say yaml-rust2 is probably not the greatest name in the world.

I don't really think having an org for that is this worthwhile, as this project is fairly small.

Even though the project is small, having an org with multiple maintainers would be nice to try to keep the bus factor above 1 and avoid a repeat of yaml-rust, and also means that it doesn't need to be relocated again in a hypothetical future where @Ethiraric stops maintaining it. But that's also predicated on being able to find multiple maintainers.

@Ethiraric I'm also curious if you encounter the issue I was describing when opening PRs against this repo. Do they go to https:/chyh1990/yaml-rust by default?

[Ethiraric]

Even though the project is small, having an org with multiple maintainers would be nice

This is already the case with @davvid as a collaborator on both Github and crates.io. If it were that I did not have time to maintain that crate, @davvid would be able to contact crates.io and ask about taking ownership.

I'm also curious if you encounter the issue I was describing when opening PRs against this repo

I have once clicked a link that was spit by git push and linked to opening a PR. I just wanted to check the overall diff on Github, but it did indeed suggest pushing to chyh1990's repository instead of mine. I disregarded that fact without much thought at the time, though.

[jplatte]

An org would also be a perfect place for a maintained fork of serde_yaml, because that one is also deprecated 🥲

[Ethiraric]

I had wanted to rename the crate zephyr when a friend suggested that name for it is a strong wind (evoking speed) from the west (which funnily reminds me of YAML's indentation).

The crate name is taken on crates.io but unused. I've contacted the owner to see if I could get the name. I pre-emptively created the zephyr-rs organization in Github in case they accept, and I'll try to make it home to all the YAML stuff that I have in mind and the community needs.

There is a bunch of code that I have written in this repository that could benefit from being taken out of this repository to their own. This would also allow splitting the parser from the actual API, allowing a serde-compatible create to be created from the parser here.

[Ethiraric]

I have split the crate into 2 different crates: one for the parser, and one for the user facing API. The end goal is to ideally have the benchmark separated from the parser, but this already lays some groundwork. The serde implementation will be able to share the parser, allowing for uniform YAML parsing in Rust.

All repositories will be found at https:/orgs/saphyr-rs/repositories. The 2 repositories have the current yaml-rust2 crate as a git ancestor, but aren't considered as forks for Github. This then fixes this issue. I'll get to moving issues that are extensions to this crate to issues in saphyr.

This crate will still be maintained for a while, but will not receive new additions. Those will go to saphyr. In the first few weeks where this crate has lived, we have already had to push the minor 3 times because of API breaks, and that is not a pace we can continue on. There are a bunch of improvements to be made on the API, and having a new name and versioning will allow for easier tweaking while we get to an API that is cleanly designed. Needless to say there will be a lot of API breaks in the early days of saphyr.

Ideally, this would all be ready for people to switch (again) their YAML library, but my point of view is that I'd rather have this for people who do not really want to bother with their YAML dependency and saphyr for those who want a nice user-friendly API, at the cost of some API breaks. Switching libraries once has already been painful for some, so I'll try to have the next one be the last.

[Ethiraric]

@davvid You should have received invitations for the organizations as well as on crates.io

[tarcieri]

@Ethiraric nice!

Have you considered a monorepo with a crate workspace containing both saphyr and saphyr-parser, rather than two git repos?

That would make it easier to do cross-cutting work across both of them.

[Ethiraric]

I have, but I do want them to be two distinct and independent blocks. There is very little binding the two together; mostly just the Event variant.