Hi Krisztian, When you say that using GitHub issues is "not the apache way of issue tracking", are you referring to any particular ASF rules? I see no mention of JIRA in https://www.apache.org/theapacheway/ and there are other Apache projects (such as Airflow) that use GitHub issues.
Thanks, Andy. On Mon, Apr 12, 2021 at 7:41 AM Krisztián Szűcs <szucs.kriszt...@gmail.com> wrote: > 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 >
