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 implementation / component, with no intentions of being mergeable in the traditional sense. Operationally, the first case would be things like mv new_repo/* old_repo/component/ The second case would be for things like rm -rf old_repo/*; mv new_repo/* old_repo/ or "this repo is now official code, old is in maintenance mode". Best, Jorge On Mon, Apr 26, 2021 at 6:40 AM Micah Kornfield <emkornfi...@gmail.com> wrote: > 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 at 9:31 PM Jorge Cardoso Leitão < > jorgecarlei...@gmail.com> wrote: > > > 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 the context and governance > of > > that work, while still offering the freedoms that people enjoy when > > creating a new repo on their personal accounts. > > > > I wrote a draft proposal here: [1] > > > > [1] > > > > > https://docs.google.com/document/d/1rDTWezkKkmOQ3HQeX8NhaXbKZLeuwcyFdC4ZA7ZatDY/edit?usp=sharing > > > > Best, > > Jorge > > >
