On Mon, Apr 12, 2021 at 6:55 AM 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. >
As an Airflow committer, I can confirm that switching from JIRA to github issue resulted in a very positive productivity gain for the community. This experience actually made me think more ASF projects that use Github for code review should give Github issue a try. > > Cons: > > - not the apache way of issue tracking > > - doubtful outcome for large number of issues > > In general, as long as it's within the ASF rules and not hurting productivity for other language implementations, we should encourage developers to explore new tools and management structures. Doing things just because that's how it was done in the past is usually not a good argument :) That said, I understand Krisztian's concern of this turning into something worse than JIRA. In the worst case, we can always declare this a failed experiment and go back to JIRA. But the upside is so much more. Either case, I believe there will be no extra work for the non-Rust developers. > > 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 > >
