[DISCUSS] Dev branches under apache/calcite

[Stamatis Zampetakis <za...@gmail.com>]

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?commits@calcite.apache.org
[3] https://ci-builds.apache.org/job/Calcite/job/Calcite-sonar/
[4] https://github.com/apache/calcite/actions?query=

Re: [DISCUSS] Dev branches under apache/calcite

[Ruben Q L <ru...@gmail.com>]

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.solimando@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 <za...@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?commits@calcite.apache.org
> > [3] https://ci-builds.apache.org/job/Calcite/job/Calcite-sonar/
> > [4] https://github.com/apache/calcite/actions?query=
> >
>

Re: [DISCUSS] Dev branches under apache/calcite

[Alessandro Solimando <al...@gmail.com>]

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 <za...@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?commits@calcite.apache.org
> [3] https://ci-builds.apache.org/job/Calcite/job/Calcite-sonar/
> [4] https://github.com/apache/calcite/actions?query=
>