I think we are ready for a vote On Tue, Apr 13, 2021, 20:44 Andy Grove <andygrov...@gmail.com> wrote:
> There has been a lot of discussion both in this email thread and in > comments in the Google document and all the comment threads in the document > have been resolved. > > Is there more work that needs to happen in the proposal before we go to a > vote, or do we have enough detail for us to move forward with the vote? > > Thanks, > > Andy. > > > > On Mon, Apr 12, 2021 at 7:42 PM QP Hou <q...@scribd.com.invalid> wrote: > > > 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 > > > > > > >
