Our contributing guidelines [1] state that a fork must be used, so I'd say that should be the way to proceed (unless there's an exceptional circumstance).
Best, Ruben [1] https://calcite.apache.org/develop/#contributing On Tue, Apr 29, 2025 at 11:32 AM Alessandro Solimando < alessandro.solima...@gmail.com> wrote: > Hi Stamatis, > thank you for bringing this up. > > Personally, I am used to the fork-based approach and I have never > experienced the need to create a branch under the apache/calcite repo that > I couldn't achieve via a branch in the fork + a (sometimes draft) PR. > > Not against either if there is a rationale, otherwise I prefer we keep the > apache/calcite repo as clean as possible. > > Best regards, > Alessandro > > On Tue, 29 Apr 2025 at 11:36, Stamatis Zampetakis <zabe...@gmail.com> > wrote: > > > Hey everyone, > > > > I noticed that some committers occasionally create dev branches under > > the main apache/calcite repository [1]. > > > > Working directly under the main apache/calcite repo has some side > effects: > > * Extra noise and duplicate notifications in commits list [2] > > * Duplicate CI runs on Jenkins [3] and GitHub [4] > > * Maintenance overhead to get rid off the branches once development cedes > > > > I am not against this contribution model although the fork-based > > contribution workflow is more commonly used and does not have the > > above side-effects. If there is no particular reason for creating > > branches under the main repo, I would favor the fork-based approach. > > > > Best, > > Stamatis > > > > [1] https://github.com/apache/calcite/branches/all > > [2] https://lists.apache.org/list.html?comm...@calcite.apache.org > > [3] https://ci-builds.apache.org/job/Calcite/job/Calcite-sonar/ > > [4] https://github.com/apache/calcite/actions?query= > > >
