I think we are ready for a vote
On Tue, Apr 13, 2021, 20:44 Andy Grove 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 t
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 wit
On Mon, Apr 12, 2021 at 6:55 AM Andy Grove 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
>
On Mon, Apr 12, 2021 at 10:12 AM Krisztián Szűcs
wrote:
>
> On Mon, Apr 12, 2021 at 4:44 PM Wes McKinney wrote:
> >
> > hi Krisztian,
> >
> > On Mon, Apr 12, 2021 at 8:41 AM Krisztián Szűcs
> > wrote:
> > >
> > > Hi,
> > >
> > > Based on the google document I see one actual problem and two actio
On Mon, Apr 12, 2021 at 4:44 PM Wes McKinney wrote:
>
> hi Krisztian,
>
> On Mon, Apr 12, 2021 at 8:41 AM Krisztián Szűcs
> wrote:
> >
> > Hi,
> >
> > Based on the google document I see one actual problem and two actions
> > not explicitly solving the real issue.
> >
> > # Issue: Decouple release
hi Krisztian,
On Mon, Apr 12, 2021 at 8:41 AM Krisztián Szűcs
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 proj
On Mon, Apr 12, 2021 at 3:54 PM Andy Grove 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
>
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,
And
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
>
> Continuing to grow the community is important, so
>
I would recommend that the most active contributors compensate for
> this with higher level discussions (e-mails / google documents) that
> get circulated on the mailing list, or GitHub issues. I would be
> concerned about using GitHub issues
I'm supportive of this if it addresses most of the issues that folks
in the Rust community have been having.
A handful of thoughts
* Small nit: the DataFusion repository probably needs to be called
apache/arrow-datafusion, so that all repos related to the Arrow TLP
have a common prefix. Example:
Hi Jacob,
My understanding is that our integration tests can be roughly summarized as
follows:
* Every Implementation compiles 4 binaries:
* a consumer (validate)
* a producer (json_to_file)
* a flight server
* a flight client
These binaries are used via a CLI.
* The produce
I have been working on an arrow-was library that uses the rust crate. I
was hoping to eventually merge this into the arrow repo. Since wasm is
often used on the web, I was hoping to maybe use the wasm library as a core
for the arrow-js library (which is in the main arrow repo).
So there is just o
Jorge,
* in rust, run integration tests against the latest apache/master on every
> PR
>
I've started to familiarize myself with the archery integration framework
over the last few days. Could you clarify for the "archery novices" what
exactly ^ this line would mean? Does apache/master refer to t
Hi,
Wrt to integration tests, I agree that it is important to have a plan prior
to this.
What we have been doing in the apache/arrow:
1. only release if integration tests pass against each other
2. release the signed tar with the latest of every implementation (i.e.
master)
My suggestion for in
Hi,
The major problem that we are addressing with an independent release cycle
is that the
large majority of our users do not use released versions, neither from ASF
archives nor
from Cargo crates. They use a git hash commit. This is a problem because
our git hashes
are *de facto* releases.
This
On Fri, Apr 9, 2021 at 4:57 PM Weston Pace wrote:
> Note, these problems technically exist now with the concept that any
> language can release a patch at any time. Also, since Rust isn't
> directly compiling against other Arrow libs and we are only talking
> about interoperability it's probably
> I'm assuming the idea is that the existing integration tests will remain in
> apache/arrow. Will you also run the integration test suites on your rust
> repository CI checks?
Furthermore, against what version will these tests run?
* If Arrow runs against the latest release of Rust then it wil
>
> With this explanation do you still have a concern? There is no suggestion
> of making releases that depend on GitHub hashes.
No, I don't think so. IIUC you are saying the crates dependency does not
imply the crate artifacts are published elsewhere. This sounds inline with
policies to me. Fo
Hi Micah,
During development, the Rust crates have local dependencies on each other
based on relative file system paths. At release time, we change these to
versioned dependencies before publishing, because it isn't possible to
publish a crate that depends on non-published crates.
With the code i
>
> " Crates can depend on GitHub commit hashes between releases"
This sounds like it might not align with ASF release policies [1].
[1] https://www.apache.org/legal/release-policy.html#release-definition
On Fri, Apr 9, 2021 at 1:34 PM Neal Richardson
wrote:
> Thanks, Andy. Two areas of conc
I personally believe we should continue to release the rust arrow crate in
such a way that the major versions match the other implementations, for
precisely the reasons you mention.
On Fri, Apr 9, 2021 at 4:34 PM Neal Richardson
wrote:
> Thanks, Andy. Two areas of concern I think we should hav
Thanks, Andy. Two areas of concern I think we should have some answer for
before going forward with this (and I make no opinions as to what the
"right" answers are, just raising them for discussion):
1. Integration testing: what is our workflow for ensuring that our
implementations are integration
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
24 matches
Mail list logo
