Re: Proposing new ostreedev/ Rust repositories: ostree-ext and ostree-container

["Will Manley" <ostree williammanley net>]

>  - github.com/ostreedev/ostree: introspectable C library exists as it 
> does today in ostreedev/ostree (there's also the /usr/bin/ostree CLI; 
> will get back to that in a bit)
>  - crates.io/crates/ostree: Rust bindings for libostree as it exists 
> today (at https://gitlab.com/fkrull/ostree-rs)
>  - github.com/ostreedev/ostree-ext: A new repository moved from 
> https://github.com/cgwalters/ostree-ext/
>  - github.com/cgwalters/ostree-container: A new repository migrated 
> from https://github.com/cgwalters/ostree-container

I'd support this proposal, but I think it would be better if all the code were in the same repo.  I think it 
makes communication easier.  There would be a single place to raise issues and watch and discuss PRs.  It 
also means that you can have single PRs that touch multiple areas atomically - for example updating some GI 
annotation and some manual rust binding at the same time.  This keeps all the context of a change together.

Having an atomic git commit is also much more convenient than having to make a release in a dependency so you 
can refer to the new version in your dependant project - and much more "correct" than figuring it out 
manually based on commit dates and messages.  This becomes particularly important when trying to apply 
automated testing across the project.

Rust has built in support for this in the form of Cargo workspaces. You have a single repo with 
subdirectories for each of your crates, and they can refer to each other using { path="../ostree" } 
references.  In our case it would be like that, but one of the crates wouldn't be a crate - it would be the 
current ostree project.  The build system for ostree wouldn't have to change.  In terms of Debian packaging 
it would be a single source package with multiple binary packages built from it.

My experience of working on multi-repo projects like GStreamer is that it becomes a PITA when you're working 
on some new feature that requires new foundational changes too.

Thanks

Will