Open redradist opened 11 months ago
I agree in principle; I talked about doing exactly this with some OpenVINO maintainers some time ago. But, IIRC, I had some concerns about the CI setup (which looks now to me like it has improved) and whether that repository would impose arbitrary constraints on merges. I think at this point the question should be whether moving the repository there improves the maintenance of these crates in any way: if there are interested Rust contributors there and that repository keeps these bindings more in sync with OpenVINO releases, then I think moving this there could make sense.
@abrown
I agree in principle; I talked about doing exactly this with some OpenVINO maintainers some time ago. But, IIRC, I had some concerns about the CI setup (which looks now to me like it has improved) and whether that repository would impose arbitrary constraints on merges. I think at this point the question should be whether moving the repository there improves the maintenance of these crates in any way: if there are interested Rust contributors there and that repository keeps these bindings more in sync with OpenVINO releases, then I think moving this there could make sense.
I think it not only increase maintainability, but also will allow other developers as me much faster to find some packages related to OpenVINO
I think it not only increase maintainability
Yeah, I think it could increase maintainability but only if there are more people committed to maintaining it. Thanks for opening the issue over there; let's see if there is any interest to help out.
will allow other developers as me much faster to find some packages related to OpenVINO
Another thing we could do immediately is simply add documentation to that repository (e.g., in the README) pointing users to the OpenVINO crates on crates.io: https://crates.io/crates/openvino. That will link back to whatever repository the crate is associated with, which might not be too relevant to the average Rust user; most interaction with crates is directly through crates.io, not the source repository.
@abrown Have you seen the answer on my question in [Question] Moving rust_api into OpenVINO Contrib ?
Looks guys are intrested in rust_api
in that repo. Would you create PR ?
Yes, I saw that. I didn't see any discussion on whether developers there are committed to contributing to the various crates, though. Like I mentioned above, I think that's a critical piece to this; otherwise, let's not "fix" something that's not broken — the current repository is working fine. I'm frequently available on Zulip; do you want to set up a meeting with the right people?
@abrown
Yes, I saw that. I didn't see any discussion on whether developers there are committed to contributing to the various crates, though. Like I mentioned above, I think that's a critical piece to this; otherwise, let's not "fix" something that's not broken — the current repository is working fine. I'm frequently available on Zulip; do you want to set up a meeting with the right people?
Once it become a single repo in openvino_contrib
repository it will earlier solving the issues, because it is located in single place and anybody who intrested in OpenVINO can find it earlier
You are both Intel employees, could you contact internally with @alvoron or @ilya-lavrenov ?
I ended up meeting with both @alvoron and @ilya-lavrenov about this. While not ruling out any future move, I think in the short term we can safely wait:
openvino_contrib
to point users to how to use the Rust bindingsIdeally, these Rust bindings could live adjacent to the C bindings in the main repository, not in openvino_contrib
, so it can always stay up to date. The three steps above are towards that direction. No one on the OpenVINO core team has the time to take on the additional work of these Rust bindings, so I'll be working on these as I can. @redradist, are you also interested in contributing?
For me it looks like it make sense to move this repo in openvino_contrib just like it is done for java_api