Jorge, do you think linking the doc or copying this to someplace on the
Arrow website to make it more visible would make sense?
On Tue, Apr 27, 2021 at 2:51 PM Wes McKinney wrote:
> This process seems pretty reasonable to me. Thanks for writing up the
> document.
>
> On Tue, Apr 27, 2021 at 10:
This process seems pretty reasonable to me. Thanks for writing up the
document.
On Tue, Apr 27, 2021 at 10:56 AM Micah Kornfield
wrote:
> Hi Jorge,
> I think especially for the second case, it might be better to keep things
> on branches in the repro even if they aren't quite mergeable. Even fo
Hi Jorge,
I think especially for the second case, it might be better to keep things
on branches in the repro even if they aren't quite mergeable. Even for the
first case, I would potentially aim for the "closest possible" repo with a
new branch.
I think standalone repos tend to indicate a higher
Hi Micah,
For code that is mergeable, I would say that a branch is superior, as it
keeps lineage and thus enables rebasing. IMO there are two use-cases for
this mechanism:
* create a new component from scratch (e.g. Ballista, bindings to language
Z, python-datafusion).
* re-write an existing impl
Hi Jorge,
Thanks for doing this.
One question that springs to mind: For work that is mostly intended to be
merged back to an existing Arrow repo what are the trade-offs between brand
new repos as compared to a separate branch in existing one in an existing
one?
Cheers,
Micah
On Sun, Apr 25, 2021
Hi,
As discussed in other threads (rust sync and parquet2), I would like to
open the discussion around opening repos for experimental work that may or
may not be merged / used.
The rationale is that we incentivise work to be conducted within ASF and
Apache Arrows' governance, thereby clarifying t
