This process seems pretty reasonable to me. Thanks for writing up the document.
On Tue, Apr 27, 2021 at 10:56 AM Micah Kornfield <emkornfi...@gmail.com> 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 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 level of > maturity/commitment to casual observers that these experiments are meant to > represent (even clearly documented experimental repos). I think once the > project reaches some level of maturity and there is broader community > commitment the decision/technical part can be made to spinning new repos. > > Again, this isn't based on any data or any real experience so I'm happy for > whoever wants to try out the process to go the way they see fit. I also > guess there might be some technical implications for some languages based > on branches/repos. > > Cheers, > Micah > > On Mon, Apr 26, 2021 at 8:44 AM Jorge Cardoso Leitão < > jorgecarlei...@gmail.com> wrote: > > > 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 > >> > > >> > > >
