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 <wesmck...@gmail.com> wrote: > 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 >> >> > >> >> >> > >> >
