On Mon, Apr 12, 2021 at 3:54 PM Andy Grove <andygrov...@gmail.com> wrote: > > 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. No, I mean most of the apache projects use JIRA for issue tracking.
My point is that we don't need to create new repositories in order to 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 > >
