[RESULT] [VOTE] Donation of rust arrow2 and parquet2
With 10 +1, 3 +1 non-binding, and no 0 nor -1, the vote passed. Thank you all for your participation and for this clarification. I will start work with the incubator for the IP clearance. Best, Jorge
Re: Moving "Improvements" and "New Features" to 6.0.0 release
Can you leave the ones marked “in progress” or that have the pull-request-available label? On Thu, Jul 1, 2021 at 11:06 PM Alessandro Molina < alessan...@ursacomputing.com> wrote: > Hi everybody, > > Given that the expected time for release 5.0.0 is approaching and there are > 160+ Jira issues assigned to that release ( > https://cwiki.apache.org/confluence/display/ARROW/Arrow+5.0.0+Release ) > I'd > like to propose to do some cleanup of the TODO by bulk moving all 5.0.0 > jira issues flagged as "Improvement" or "New Feature" to 6.0.0. That will > reduce the scope of Jira issues for 5.0.0 to ~30 bugs which seems a > more manageable goal. > > If anyone has a new feature or improvement they are working on and want to > include in 5.0.0, those ones will obviously still be able to go. What I'm > proposing is just to move the issues by default and then in case anyone > wants to keep some of them in 5.0.0 they can be moved back. > > In general if we move an issue you are involved on, you should receive a > notification and should be able to move it back to 5.0.0 if you want to > ship it in that release. > > I hope this helps getting a better understanding of what's going to go in > 5.0.0 so that release announcements can be more easily prepared > > Any thoughts? >
Re: [VOTE] Arrow should state a convention for encoding instants as Timestamp with "UTC" as the time zone
+1 Kazuaki Ishizaki "Weston Pace" wrote on 2021/06/30 18:52:46: > From: "Weston Pace" > To: dev@arrow.apache.org > Date: 2021/06/30 18:53 > Subject: [EXTERNAL] [VOTE] Arrow should state a convention for > encoding instants as Timestamp with "UTC" as the time zone > > This vote is a result of previous discussion[1][2]. This vote is also > a prerequisite for the PR in [5]. > > --- > Some date & time libraries have three temporal concepts. For the sake > of this document we will call them LocalDateTime, ZonedDateTime, and > Instant. An Instant is a timestamp that has no meaningful reference > time zone (e.g. events that did not occur on Earth or columns of > timestamps spanning more than one time zone). For more extensive > definitions and a discussion of their semantics and uses see [3]. > Currently Arrow describes how to encode two of these three concepts > into a Timestamp column and there is no guideline on how to store an > Instant. > > > This proposal states that Arrow should recommend that instants be encoded > into timestamp columns by setting the timezone string to "UTC". > --- > > For sample arguments (currently grouped as "for changing schema.fbs" > and "against changing schema.fbs") see [4]. For a detailed definition > of the terms LocalDateTime, ZonedDateTime, and Instant and a > discussion of their semantics see [3]. For a straw poll on > possible ways to handle instants see [2]. > > This vote will be open for at least 72 hours. > > [ ] +1 Update schema.fbs to state the above convention > [ ] +0 > [ ] -1 Do not make any change > > [1] INVALID URI REMOVED > u=https-3A__lists.apache.org_thread.html_r8216e5de3efd2935e3907ad9bd20ce07e430952f84de69b36337e5eb-2540-253Cdev.arrow.apache.org-253E&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f- > ZCGj9Pg&m=avV0JpLmaymMbxpZiYwNb9Yug7bj3PGiNYiJCM-x3kY&s=Ty-Oq- > Gfuo2KRdogmjFFOLvji5yQ0LrrBZWWO7hDufs&e= > [2] INVALID URI REMOVED > u=https-3A__lists.apache.org_thread.html_r1bdffc76537ae9c12c37396880087fee9c0eec9000bf6ed4c9850c44-2540-253Cdev.arrow.apache.org-253E&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f- > ZCGj9Pg&m=avV0JpLmaymMbxpZiYwNb9Yug7bj3PGiNYiJCM- > x3kY&s=NyxlTSPly7kAqwMiuXS7BH0lZkK3W0VmVSvvRF-ANa8&e= > [3] INVALID URI REMOVED > u=https-3A__docs.google.com_document_d_1QDwX4ypfNvESc2ywcT1ygaf2Y1R8SmkpifMV7gpJdBI_edit-3Fusp-3Dsharing&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f- > ZCGj9Pg&m=avV0JpLmaymMbxpZiYwNb9Yug7bj3PGiNYiJCM- > x3kY&s=opFrDCQFvlSmY31hxs8MDKLcUe3muSTaNXosFCaPX5U&e= > [4] INVALID URI REMOVED > u=https-3A__docs.google.com_document_d_1xEKRhs-2DGUSMwjMhgmQdnCNMXwZrA10226AcXRoP8g9E_edit-3Fusp-3Dsharing&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f- > ZCGj9Pg&m=avV0JpLmaymMbxpZiYwNb9Yug7bj3PGiNYiJCM- > x3kY&s=fIjWMI0tuH57ffsGzpOX85d5Dd7TN4tT_h0cj1elNbw&e= > [5] INVALID URI REMOVED > u=https-3A__github.com_apache_arrow_pull_10629&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f- > ZCGj9Pg&m=avV0JpLmaymMbxpZiYwNb9Yug7bj3PGiNYiJCM- > x3kY&s=RQrwm8rHhpbx-6JbTZ4WMVpWGrUIu7Ns7oGrfLMk2uQ&e=
Moving "Improvements" and "New Features" to 6.0.0 release
Hi everybody, Given that the expected time for release 5.0.0 is approaching and there are 160+ Jira issues assigned to that release ( https://cwiki.apache.org/confluence/display/ARROW/Arrow+5.0.0+Release ) I'd like to propose to do some cleanup of the TODO by bulk moving all 5.0.0 jira issues flagged as "Improvement" or "New Feature" to 6.0.0. That will reduce the scope of Jira issues for 5.0.0 to ~30 bugs which seems a more manageable goal. If anyone has a new feature or improvement they are working on and want to include in 5.0.0, those ones will obviously still be able to go. What I'm proposing is just to move the issues by default and then in case anyone wants to keep some of them in 5.0.0 they can be moved back. In general if we move an issue you are involved on, you should receive a notification and should be able to move it back to 5.0.0 if you want to ship it in that release. I hope this helps getting a better understanding of what's going to go in 5.0.0 so that release announcements can be more easily prepared Any thoughts?
