Hi, Based on the google document I see one actual problem and two actions not explicitly solving the real issue.
# Issue: Decouple release process to enable independent releases This is something the whole project requires, not just the rust implementation. Eventually every implementation should have its own release cycle not blocked on others. Even if we want to tackle this just for the rust implementation in the first iteration, we need to figure out the right versioning scheme, voting process and integration testing. Note that we have already decided to decouple the source release process from the release of the binaries. We also need to figure out how to handle the source release itself once we provide different artifacts for different implementations. # Action 1: Maintain the rust implementation in additional apache repositories Pros: - presumably would make it easier to define the dependencies between the rust crates (though cargo should support multiple crates in a single repository) Cons: - inconsistent: if there is apache/arrow-rs why isn't there apache/arrow-js - decrease project visibility: having all of the implementations in a single repository makes other implementations trivial to find - introduces a lot of complexity for the CI/CD processes, and not just for the rust folks - will make harder to interface/link between different implementations This seems unreasonable to me. # Action 2: Use github for issue tracking Pros: - easier for new contributors - more flexible in certain ways Cons: - not the apache way of issue tracking - doubtful outcome for large number of issues I don't like either JIRA but I can live with it, though I understand the frustration around it. Since GH issues vs. JIRA seems like a hot topic lately we could try to experiment with a less radical change: enable github issues for the whole project and sync them to JIRA (either by using an existing service or by developing a github action for it). We may end up preferring github issues eventually. All in all, I find this proposal way too invasive. It sounds more like starting a new project with its own governance rather than making releases more accessible to users. Thanks, Krisztian On Fri, Apr 9, 2021 at 5:18 PM Andy Grove <andygrov...@gmail.com> wrote: > > Following on from the email thread "Rust sync meeting" I would like to > start a new discussion about moving the Rust components out to new GitHub > repositories and using a new process for issues and release management. > > I have started a Google document [1] with details and to track the work > required for this effort but I will summarize the key points of the > proposal here: > > > - > > Move existing Rust code into two new repositories > - > > apache/arrow-rs > - > > Arrow + Parquet crates > - > > apache/datafusion > - > > DataFusion + Ballista crates (which are expected to merge to some > degree over time) > - > > TPC-H benchmarks > - > > Use GitHub issues for issue tracking > - > > Decouple release process > - > > Crates are released individually > - > > A vote on the source release of the released crate is held over the > mailing list as usual. > - > > Rust does not need to release a new version when the rest of Arrow > releases; we bundle our latest released crates to the signed tar. > - > > Crates can depend on GitHub commit hashes between releases > > > The Google document may be the best place to collaborate on the proposal > but I can update the document based on any comments in this email thread as > well. > > Note that I have excluded discussion about arrow2/parquet2 from this > proposal and I believe we should discuss that separately as a follow-on > discussion. > > I look forward to hearing opinions on this both from current Rust > maintainers and contributors and also from the wider Arrow community. > > Thanks, > > Andy. > > [1] > https://docs.google.com/document/d/1TyrUP8_UWXqk97a8Hvb1d0UYWigch0HAephIjW7soSI/edit?usp=sharing
