Mailing List Archive

On Wed, Apr 12, 2023 at 12:26?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> On Wed, Apr 12, 2023 at 12:18?PM ylavic <notifications@github.com> wrote:
> >
> > @ylavic approved this pull request.
> >
> > Three approvals to get ci started?
>
> Nope.. It seems that gh actions don't run for PRs whatever we do.
> The docs[1] say that there should be an "Approve and run" button near
> the "workflow awaiting approval" text, but it's not the case for httpd
> mirror, while approving the whole PR looks inefficient..

We (PMC/committers) once had the right to close any PRs, but that
seems to not be the case anymore either.
Something changed since
https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
probably.

>
> Any more ideas? Help from infra needed?
>
> Regards;
> Yann.
>
> [1] https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks

On Wed, Apr 12, 2023 at 6:36?AM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> On Wed, Apr 12, 2023 at 12:26?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
> >
> > On Wed, Apr 12, 2023 at 12:18?PM ylavic <notifications@github.com> wrote:
> > >
> > > @ylavic approved this pull request.
> > >
> > > Three approvals to get ci started?
> >
> > Nope.. It seems that gh actions don't run for PRs whatever we do.
> > The docs[1] say that there should be an "Approve and run" button near
> > the "workflow awaiting approval" text, but it's not the case for httpd
> > mirror, while approving the whole PR looks inefficient..
>
> We (PMC/committers) once had the right to close any PRs, but that
> seems to not be the case anymore either.
> Something changed since
> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
> probably.
>
> >
> > Any more ideas? Help from infra needed?
> >
> > Regards;
> > Yann.
> >
> > [1] https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks


We are chatting with Daniel about it on ASF slack.

--
Eric Covener
covener@gmail.com

On 4/12/23 12:35 PM, Yann Ylavic wrote:
> On Wed, Apr 12, 2023 at 12:26?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>>
>> On Wed, Apr 12, 2023 at 12:18?PM ylavic <notifications@github.com> wrote:
>>>
>>> @ylavic approved this pull request.
>>>
>>> Three approvals to get ci started?
>>
>> Nope.. It seems that gh actions don't run for PRs whatever we do.
>> The docs[1] say that there should be an "Approve and run" button near
>> the "workflow awaiting approval" text, but it's not the case for httpd
>> mirror, while approving the whole PR looks inefficient..
>
> We (PMC/committers) once had the right to close any PRs, but that
> seems to not be the case anymore either.
> Something changed since
> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
> probably.

I guess we need help from infra. Is it possible that we cannot do all this because our git repository is just a readonly mirror of
the Subversion repository and hence none of us is a maintainer of this repository?

Regards

Rüdiger

>

On Wed, Apr 12, 2023 at 1:31?PM Eric Covener <covener@gmail.com> wrote:
>
> On Wed, Apr 12, 2023 at 6:36?AM Yann Ylavic <ylavic.dev@gmail.com> wrote:
> >
> > On Wed, Apr 12, 2023 at 12:26?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
> > >
> > > On Wed, Apr 12, 2023 at 12:18?PM ylavic <notifications@github.com> wrote:
> > > >
> > > > @ylavic approved this pull request.
> > > >
> > > > Three approvals to get ci started?
> > >
> > > Nope.. It seems that gh actions don't run for PRs whatever we do.
> > > The docs[1] say that there should be an "Approve and run" button near
> > > the "workflow awaiting approval" text, but it's not the case for httpd
> > > mirror, while approving the whole PR looks inefficient..
> >
> > We (PMC/committers) once had the right to close any PRs, but that
> > seems to not be the case anymore either.
> > Something changed since
> > https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
> > probably.
> >
> > >
> > > Any more ideas? Help from infra needed?
> > >
> > > Regards;
> > > Yann.
> > >
> > > [1] https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
>
>
> We are chatting with Daniel about it on ASF slack.

Ah ok, I created https://issues.apache.org/jira/browse/INFRA-24457 FWIW..

Regards;
Yann.

On 4/12/23 2:02 PM, Yann Ylavic wrote:
> On Wed, Apr 12, 2023 at 1:31?PM Eric Covener <covener@gmail.com> wrote:
>>
>> On Wed, Apr 12, 2023 at 6:36?AM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>>>
>>> On Wed, Apr 12, 2023 at 12:26?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>>>>
>>>> On Wed, Apr 12, 2023 at 12:18?PM ylavic <notifications@github.com> wrote:
>>>>>
>>>>> @ylavic approved this pull request.
>>>>>
>>>>> Three approvals to get ci started?
>>>>
>>>> Nope.. It seems that gh actions don't run for PRs whatever we do.
>>>> The docs[1] say that there should be an "Approve and run" button near
>>>> the "workflow awaiting approval" text, but it's not the case for httpd
>>>> mirror, while approving the whole PR looks inefficient..
>>>
>>> We (PMC/committers) once had the right to close any PRs, but that
>>> seems to not be the case anymore either.
>>> Something changed since
>>> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
>>> probably.
>>>
>>>>
>>>> Any more ideas? Help from infra needed?
>>>>
>>>> Regards;
>>>> Yann.
>>>>
>>>> [1] https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
>>
>>
>> We are chatting with Daniel about it on ASF slack.
>
> Ah ok, I created https://issues.apache.org/jira/browse/INFRA-24457 FWIW..
>

I would like to bring this back here, now that we have an answer in the ticket.
The root cause for the current situation seems to be that our Github repository is just a read only mirror of our Subversion
repository. Approving PR's requires write permissions to the Github repository.

As far as I understand from the ticket we have two options:

1. We establish a monitoring process on PR's that ensures that we detect misuse of Github actions by non committers.
Then Infra could set the PR's back to "auto-approval".

2. We switch from Subversion to Git and use Git as our read / write main repository.

My 2 cents on the options:

1. I am not sure which exact monitoring will be sufficient, but it may put some larger burden on us to ensure that we
detect misuse in a timely manner. Furthermore the question to me will be what we can do to stop misuse quickly if we
detect it.

2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some
overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion.
We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL.
Apart from technical aspects that this change would create we should check if all of the current active committers are fine
using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of
Github when we would do this switch and I think this cannot be done if active committers would have issues with Github.


Regards

Rüdiger

On Tue, Apr 25, 2023 at 2:45?AM Ruediger Pluem <rpluem@apache.org> wrote:
>
>
>
> On 4/12/23 2:02 PM, Yann Ylavic wrote:
> > On Wed, Apr 12, 2023 at 1:31?PM Eric Covener <covener@gmail.com> wrote:
> >>
> >> On Wed, Apr 12, 2023 at 6:36?AM Yann Ylavic <ylavic.dev@gmail.com> wrote:
> >>>
> >>> On Wed, Apr 12, 2023 at 12:26?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
> >>>>
> >>>> On Wed, Apr 12, 2023 at 12:18?PM ylavic <notifications@github.com> wrote:
> >>>>>
> >>>>> @ylavic approved this pull request.
> >>>>>
> >>>>> Three approvals to get ci started?
> >>>>
> >>>> Nope.. It seems that gh actions don't run for PRs whatever we do.
> >>>> The docs[1] say that there should be an "Approve and run" button near
> >>>> the "workflow awaiting approval" text, but it's not the case for httpd
> >>>> mirror, while approving the whole PR looks inefficient..
> >>>
> >>> We (PMC/committers) once had the right to close any PRs, but that
> >>> seems to not be the case anymore either.
> >>> Something changed since
> >>> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
> >>> probably.
> >>>
> >>>>
> >>>> Any more ideas? Help from infra needed?
> >>>>
> >>>> Regards;
> >>>> Yann.
> >>>>
> >>>> [1] https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
> >>
> >>
> >> We are chatting with Daniel about it on ASF slack.
> >
> > Ah ok, I created https://issues.apache.org/jira/browse/INFRA-24457 FWIW..
> >
>
> I would like to bring this back here, now that we have an answer in the ticket.
> The root cause for the current situation seems to be that our Github repository is just a read only mirror of our Subversion
> repository. Approving PR's requires write permissions to the Github repository.
>
> As far as I understand from the ticket we have two options:
>
> 1. We establish a monitoring process on PR's that ensures that we detect misuse of Github actions by non committers.
> Then Infra could set the PR's back to "auto-approval".
>
> 2. We switch from Subversion to Git and use Git as our read / write main repository.
>
> My 2 cents on the options:
>
> 1. I am not sure which exact monitoring will be sufficient, but it may put some larger burden on us to ensure that we
> detect misuse in a timely manner. Furthermore the question to me will be what we can do to stop misuse quickly if we
> detect it.
>
> 2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some
> overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion.
> We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL.
> Apart from technical aspects that this change would create we should check if all of the current active committers are fine
> using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of
> Github when we would do this switch and I think this cannot be done if active committers would have issues with Github.


I think r/w github is the way to go, but I know from previous threads
there are strong feelings against it.
Right now we seem to not be optimized for either maintainers or
contributors, it's just inertia. I think it's bad for our image.

Get over the heartache and brand loyalty and get on rw git. Github isn't
the only game in town anymore for git hosting, so don't feel trapped by
infra just because it's all they've got in the tank.

On Tue, Apr 25, 2023 at 2:07?PM Eric Covener <covener@gmail.com> wrote:

> On Tue, Apr 25, 2023 at 2:45?AM Ruediger Pluem <rpluem@apache.org> wrote:
> >
> >
> >
> > On 4/12/23 2:02 PM, Yann Ylavic wrote:
> > > On Wed, Apr 12, 2023 at 1:31?PM Eric Covener <covener@gmail.com>
> wrote:
> > >>
> > >> On Wed, Apr 12, 2023 at 6:36?AM Yann Ylavic <ylavic.dev@gmail.com>
> wrote:
> > >>>
> > >>> On Wed, Apr 12, 2023 at 12:26?PM Yann Ylavic <ylavic.dev@gmail.com>
> wrote:
> > >>>>
> > >>>> On Wed, Apr 12, 2023 at 12:18?PM ylavic <notifications@github.com>
> wrote:
> > >>>>>
> > >>>>> @ylavic approved this pull request.
> > >>>>>
> > >>>>> Three approvals to get ci started?
> > >>>>
> > >>>> Nope.. It seems that gh actions don't run for PRs whatever we do.
> > >>>> The docs[1] say that there should be an "Approve and run" button
> near
> > >>>> the "workflow awaiting approval" text, but it's not the case for
> httpd
> > >>>> mirror, while approving the whole PR looks inefficient..
> > >>>
> > >>> We (PMC/committers) once had the right to close any PRs, but that
> > >>> seems to not be the case anymore either.
> > >>> Something changed since
> > >>> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
> > >>> probably.
> > >>>
> > >>>>
> > >>>> Any more ideas? Help from infra needed?
> > >>>>
> > >>>> Regards;
> > >>>> Yann.
> > >>>>
> > >>>> [1]
> https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
> > >>
> > >>
> > >> We are chatting with Daniel about it on ASF slack.
> > >
> > > Ah ok, I created https://issues.apache.org/jira/browse/INFRA-24457
> FWIW..
> > >
> >
> > I would like to bring this back here, now that we have an answer in the
> ticket.
> > The root cause for the current situation seems to be that our Github
> repository is just a read only mirror of our Subversion
> > repository. Approving PR's requires write permissions to the Github
> repository.
> >
> > As far as I understand from the ticket we have two options:
> >
> > 1. We establish a monitoring process on PR's that ensures that we detect
> misuse of Github actions by non committers.
> > Then Infra could set the PR's back to "auto-approval".
> >
> > 2. We switch from Subversion to Git and use Git as our read / write main
> repository.
> >
> > My 2 cents on the options:
> >
> > 1. I am not sure which exact monitoring will be sufficient, but it may
> put some larger burden on us to ensure that we
> > detect misuse in a timely manner. Furthermore the question to me will
> be what we can do to stop misuse quickly if we
> > detect it.
> >
> > 2. Switching from Subversion to Git is mostly an emotional problem for
> me. We have some closer ties to Subversion by some
> > overlaps in the community and via mod_dav_svn we kind of partially
> eat our very own dogfood here by using Subversion.
> > We wouldn't do that any longer with Git. Plus it would switch another
> of our development tools from an Apache license to GPL.
> > Apart from technical aspects that this change would create we should
> check if all of the current active committers are fine
> > using Github. While people could use Gitbox and thus avoid Github
> when we use Git I would like us to leverage the features of
> > Github when we would do this switch and I think this cannot be done
> if active committers would have issues with Github.
>
>
> I think r/w github is the way to go, but I know from previous threads
> there are strong feelings against it.
> Right now we seem to not be optimized for either maintainers or
> contributors, it's just inertia. I think it's bad for our image.
>

On 25 Apr 2023, at 07:45, Ruediger Pluem <rpluem@apache.org> wrote:

> 2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some
> overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion.
> We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL.
> Apart from technical aspects that this change would create we should check if all of the current active committers are fine
> using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of
> Github when we would do this switch and I think this cannot be done if active committers would have issues with Github.

+1.

I've always found the fight about “must be git” to be really tedious. Github supports both git and svn to this day, and people are free to use what they prefer by using the interface they are most familiar with.

While Github is popular today, this is only because the goals of the owners of Github are presently aligned with our goals. As Twitter has taught us, goals change at any time and without warning.

Regards,
Graham
—

On Tue, Apr 25, 2023 at 2:45?PM Graham Leggett via dev
<dev@httpd.apache.org> wrote:
>
> On 25 Apr 2023, at 07:45, Ruediger Pluem <rpluem@apache.org> wrote:
>
> 2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some
> overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion.
> We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL.
> Apart from technical aspects that this change would create we should check if all of the current active committers are fine
> using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of
> Github when we would do this switch and I think this cannot be done if active committers would have issues with Github.
>
>
> +1.
>
> I've always found the fight about “must be git” to be really tedious. Github supports both git and svn to this day, and people are free to use what they prefer by using the interface they are most familiar with.
>
> While Github is popular today, this is only because the goals of the owners of Github are presently aligned with our goals. As Twitter has taught us, goals change at any time and without warning.

Hi Graham -- it's a little unclear to me where this would put you
"vote" wise about moving to read/write Git.

Anyone else with a stake have an opinion? It has been since about 2019
since we last discussed it here, I am hoping people have warmed up to
it.

On 2023-05-03 14:12, Eric Covener wrote:
> On Tue, Apr 25, 2023 at 2:45?PM Graham Leggett via dev
> <dev@httpd.apache.org> wrote:
>>
>> On 25 Apr 2023, at 07:45, Ruediger Pluem <rpluem@apache.org> wrote:
>>
>> 2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some
>> overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion.
>> We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL.
>> Apart from technical aspects that this change would create we should check if all of the current active committers are fine
>> using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of
>> Github when we would do this switch and I think this cannot be done if active committers would have issues with Github.
>>
>>
>> +1.
>>
>> I've always found the fight about “must be git” to be really tedious. Github supports both git and svn to this day, and people are free to use what they prefer by using the interface they are most familiar with.
>>
>> While Github is popular today, this is only because the goals of the owners of Github are presently aligned with our goals. As Twitter has taught us, goals change at any time and without warning.
>
> Hi Graham -- it's a little unclear to me where this would put you
> "vote" wise about moving to read/write Git.
>
> Anyone else with a stake have an opinion? It has been since about 2019
> since we last discussed it here, I am hoping people have warmed up to
> it.

I am +1 on moving. I do not have any particular love for git or svn on
their own, and I realize that the proposed change does make outside
contributions and certain workflows easier.

Le 03/05/2023 à 21:12, Eric Covener a écrit :
> On Tue, Apr 25, 2023 at 2:45?PM Graham Leggett via dev
> <dev@httpd.apache.org> wrote:
>>
>> On 25 Apr 2023, at 07:45, Ruediger Pluem <rpluem@apache.org> wrote:
>>
>> 2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some
>> overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion.
>> We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL.
>> Apart from technical aspects that this change would create we should check if all of the current active committers are fine
>> using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of
>> Github when we would do this switch and I think this cannot be done if active committers would have issues with Github.
>>
>>
>> +1.
>>
>> I've always found the fight about “must be git” to be really tedious. Github supports both git and svn to this day, and people are free to use what they prefer by using the interface they are most familiar with.
>>
>> While Github is popular today, this is only because the goals of the owners of Github are presently aligned with our goals. As Twitter has taught us, goals change at any time and without warning.
>
> Hi Graham -- it's a little unclear to me where this would put you
> "vote" wise about moving to read/write Git.
>
> Anyone else with a stake have an opinion? It has been since about 2019
> since we last discussed it here, I am hoping people have warmed up to
> it.
>

svn or git both fit my needs.

git would be slightly easier for me because of the feature to easily
commit only parts of changes of files (I think that some svn clients
also support it, but not the one I use)

github is great because it can be used for code review without the need
to commit something. A patch can be discussed, updated, improved, ...
cleanly before being merged. That's a great feature IMHO.

git/github would also make the project more attractive for others
contributions I think.

So, even if I personality really don't care for myself, I would +1 the
sake of the project.

Just my 2c,

CJ

> Am 03.05.2023 um 23:03 schrieb Christophe JAILLET <christophe.jaillet@wanadoo.fr>:
>
> Le 03/05/2023 à 21:12, Eric Covener a écrit :
>> On Tue, Apr 25, 2023 at 2:45?PM Graham Leggett via dev
>> <dev@httpd.apache.org> wrote:
>>>
>>> On 25 Apr 2023, at 07:45, Ruediger Pluem <rpluem@apache.org> wrote:
>>>
>>> 2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some
>>> overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion.
>>> We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL.
>>> Apart from technical aspects that this change would create we should check if all of the current active committers are fine
>>> using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of
>>> Github when we would do this switch and I think this cannot be done if active committers would have issues with Github.
>>>
>>>
>>> +1.
>>>
>>> I've always found the fight about “must be git” to be really tedious. Github supports both git and svn to this day, and people are free to use what they prefer by using the interface they are most familiar with.
>>>
>>> While Github is popular today, this is only because the goals of the owners of Github are presently aligned with our goals. As Twitter has taught us, goals change at any time and without warning.
>> Hi Graham -- it's a little unclear to me where this would put you
>> "vote" wise about moving to read/write Git.
>> Anyone else with a stake have an opinion? It has been since about 2019
>> since we last discussed it here, I am hoping people have warmed up to
>> it.
>
> svn or git both fit my needs.
>
> git would be slightly easier for me because of the feature to easily commit only parts of changes of files (I think that some svn clients also support it, but not the one I use)
>
> github is great because it can be used for code review without the need to commit something. A patch can be discussed, updated, improved, ... cleanly before being merged. That's a great feature IMHO.
>
> git/github would also make the project more attractive for others contributions I think.
>
> So, even if I personality really don't care for myself, I would +1 the sake of the project.

Many +1s

>
> Just my 2c,
>
> CJ

4.05.2023 10:25 tarihinde Stefan Eissing via dev yazd?:
>
>> Am 03.05.2023 um 23:03 schrieb Christophe JAILLET <christophe.jaillet@wanadoo.fr>:
>>
>> Le 03/05/2023 à 21:12, Eric Covener a écrit :
>>> On Tue, Apr 25, 2023 at 2:45?PM Graham Leggett via dev
>>> <dev@httpd.apache.org> wrote:
>>>> On 25 Apr 2023, at 07:45, Ruediger Pluem <rpluem@apache.org> wrote:
>>>>
>>>> 2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some
>>>> overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion.
>>>> We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL.
>>>> Apart from technical aspects that this change would create we should check if all of the current active committers are fine
>>>> using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of
>>>> Github when we would do this switch and I think this cannot be done if active committers would have issues with Github.
>>>>
>>>>
>>>> +1.
>>>>
>>>> I've always found the fight about “must be git” to be really tedious. Github supports both git and svn to this day, and people are free to use what they prefer by using the interface they are most familiar with.
>>>>
>>>> While Github is popular today, this is only because the goals of the owners of Github are presently aligned with our goals. As Twitter has taught us, goals change at any time and without warning.
>>> Hi Graham -- it's a little unclear to me where this would put you
>>> "vote" wise about moving to read/write Git.
>>> Anyone else with a stake have an opinion? It has been since about 2019
>>> since we last discussed it here, I am hoping people have warmed up to
>>> it.
>> svn or git both fit my needs.
>>
>> git would be slightly easier for me because of the feature to easily commit only parts of changes of files (I think that some svn clients also support it, but not the one I use)
>>
>> github is great because it can be used for code review without the need to commit something. A patch can be discussed, updated, improved, ... cleanly before being merged. That's a great feature IMHO.
>>
>> git/github would also make the project more attractive for others contributions I think.
>>
>> So, even if I personality really don't care for myself, I would +1 the sake of the project.
> Many +1s
>
>> Just my 2c,
>>
>> CJ

Svn to git +1

On 5/3/23 23:03, Christophe JAILLET wrote:
> Le 03/05/2023 à 21:12, Eric Covener a écrit :
>> On Tue, Apr 25, 2023 at 2:45?PM Graham Leggett via dev
>> <dev@httpd.apache.org> wrote:
>>>
>>> On 25 Apr 2023, at 07:45, Ruediger Pluem <rpluem@apache.org> wrote:
>>>
>>> 2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some
>>>    overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion.
>>>    We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL.
>>>    Apart from technical aspects that this change would create we should check if all of the current active committers are fine
>>>    using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of
>>>    Github when we would do this switch and I think this cannot be done if active committers would have issues with Github.
>>>
>>>
>>> +1.
>>>
>>> I've always found the fight about “must be git” to be really tedious. Github supports both git and svn to this day, and people are free to use what they prefer by using the interface they are most familiar with.
>>>
>>> While Github is popular today, this is only because the goals of the owners of Github are presently aligned with our goals. As Twitter has taught us, goals change at any time and without warning.
>>
>> Hi Graham -- it's a little unclear to me where this would put you
>> "vote" wise about moving to read/write Git.
>>
>> Anyone else with a stake have an opinion? It has been since about 2019
>> since we last discussed it here, I am hoping people have warmed up to
>> it.
>>
>
> svn or git both fit my needs.
>
> git would be slightly easier for me because of the feature to easily commit only parts of changes of files (I think that some svn clients also support it, but not the one I use)
>
> github is great because it can be used for code review without the need to commit something. A patch can be discussed, updated, improved, ... cleanly before being merged. That's a great feature IMHO.
>
> git/github would also make the project more attractive for others contributions I think.
>
> So, even if I personality really don't care for myself, I would +1 the sake of the project.
>
+1 for me to switch to git, code review will be easier.
Just a question, how will security diffs be managed in Github ?
Giovanni


> Just my 2c,
>
> CJ

On Wed, May 03, 2023 at 02:31:35PM -0500, Daniel Gruno wrote:
> I am +1 on moving. I do not have any particular love for git or svn on their
> own, and I realize that the proposed change does make outside contributions
> and certain workflows easier.

+1 for the same reasons here. Might be better to call a formal VOTE
thread on this with a clearer Subject.

On Tue, Apr 25, 2023 at 1:45?AM Ruediger Pluem <rpluem@apache.org> wrote:
>...

> 2. Switching from Subversion to Git is mostly an emotional problem for me.
> We have some closer ties to Subversion by some
> overlaps in the community and via mod_dav_svn we kind of partially eat
> our very own dogfood here by using Subversion.
> We wouldn't do that any longer with Git. Plus it would switch another
> of our development tools from an Apache license to GPL.
> Apart from technical aspects that this change would create we should
> check if all of the current active committers are fine
> using Github. While people could use Gitbox and thus avoid Github when
> we use Git I would like us to leverage the features of
> Github when we would do this switch and I think this cannot be done if
> active committers would have issues with Github.
>

Today 0% of httpd developers can use those features of GitHub. Switching
allows (say:) 90% of our developers, and potentially some downstream
developers and users who are familiar with "how to work with upstream code
providers, who use GitHub".

Stick with 0%, or go with "more than 0%" ?

As noted elsewhere, the GitHub Subversion support has been *sunsetted* and
will go away. That should be kept in mind. People will not be able to stick
to their svn client, whether readonly or read/write.

JoeS notes elsewhere that the git support provided by Infra is
strongly-linked to GitHub. From the Foundation's standpoint, the amount of
utility is provided is vastly higher than any business risk associated with
GitHub going dark or pulling their support for our Foundation. We have all
our data, all the provenance, and everything we need, should that day ever
arise. But it should not concern anybody in the community to create a
reliance/dependency upon GitHub.

Down-thread, Giovanni asks about security patch handling. We can continue
to use repos/private/pmc/httpd/ for that. That area will not go away. If
people want to go "all git", then Infra can provide projects with a single,
private repository that would function similarly.

IMO, I definitely think svn is a superior version control system to git. It
is much more approachable and easy to use, compared to git. I helped to
build svn, yet I use git daily; this isn't knee-jerk svn partisanship; svn
is simply better/easier. But *GitHub* is a fabulous tool. I will take the
inferior VCS in order to access the GitHub feature set. It is unfortunate
that such a site never got built for svn, but it is what it is. GitHub >
svn > git.

Cheers,
-g

On 5/5/23 2:37 AM, Greg Stein wrote:

> Down-thread, Giovanni asks about security patch handling. We can continue to use repos/private/pmc/httpd/ for that. That area will
> not go away. If people want to go "all git", then Infra can provide projects with a single, private repository that would function
> similarly.

Thanks for pointing this out. I think the repos/private/pmc/httpd should still stick in Subversion as it is now.
And it brings up another point: We need to adjust our release scripts once we made a switch.

>
> IMO, I definitely think svn is a superior version control system to git. It is much more approachable and easy to use, compared to
> git. I helped to build svn, yet I use git daily; this isn't knee-jerk svn partisanship; svn is simply better/easier. But *GitHub*

And I still use it in other areas at $work that are not that much development driven but need to version control mostly
text files and where the GitHub features are not needed / useful. For these cases svn is clearly much better suited than git.

Regards

Rüdiger