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

["Colin Walters" <walters verbum org>]

Hi,

On Wed, Apr 7, 2021, at 6:06 PM, Felix Krull via ostree-list wrote:
> Yeah, I am subscribed to the list, just didn't get around to
> replying/putting my thoughts in order.
>
> Just from an organisational perspective, I'm all for moving the Rust
> bindings into the OSTree organisation (such as it is), whether as a
> separate repo under github.com/ostreedev or as part of a future
> monorepo. With official parts of OSTree being written in Rust and
> using the Rust bindings -- as well as rpm-ostree -- I'm not keen on
> being stuck in the middle of that with my essentially-personal
> project. 

(I am a bit curious what you're using it for btw)

> I can very much do without the pressure and expectations that
> come from that. :)

OK, makes sense.  But do you have any sense of your availability?  Would you still be a reviewer for changes?

Hmm actually and we need to coordinate access to crate uploads.  Can you give me upload access to the ostree 
crate?  I just invited you to the ostreedev GH organization, so I think what we should do is make a new 
"crates" team that has uploads - actually, done.

And I just imported ostree-rs to https://github.com/ostreedev/ostree-rs and you should have access.  It now 
has the same rules as the main ostree repo - review is required to merge, and ah right, it needs a CI setup 
too to enforce status checks.  Looking at that.

> On Tue, 6 Apr 2021 at 00:18, Colin Walters <walters verbum org> wrote:
> > A more aggressive version is (and this would require Felix's buy-in) merging crates.io/crates/ostree with 
> > ostree-ext and ostree-container so we have
> >
> > github.com/ostreedev/ostree (as it exists today)
> > github.com/ostreedev/ostree-rs
>
> I'm mostly in favour of keeping the ostree and ostree-ext crates
> separate. ostree-rs is mostly gir-generated code which brings its own
> limitations (for example, the crate is still Rust 2015 because the
> generated code doesn't compile with 2018). Putting significant
> additional functionality in there might be awkward. And given that
> cargo exists, there's no strong reason to merge them IMO other than
> picking appropriate names.

Ah, I didn't know about the 2015 issue.  But yeah, mixing a lot of generated with hand-written code would be 
confusing.

OK.  Let's proceed with the setup of 3 repos:

- ostree
- ostree-rs
- ostree-rs-ext

(If anyone can think of a better name than `-ext`, now is a good time ;) )